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ABSTRACT 


The  purpose  of  this  research  was  to  develop  a  methodology  for  creating  P-3  Aircraft 
behaviors  in  the  Joint  Semi-Automated  Forces  (JSAF)  simulation  to  help  reduce  the 
workload  of  JSAF  terminal  operators,  which  saves  money  for  the  Navy  by  lowering  the 
number  of  operators  required.  JSAF  is  the  core  simulation  engine  of  the  Navy  Continuous 
Training  Environment,  which  is  used  to  connect  simulations  and  live  units  to  conduct 
Fleet  Synthetic  Training  (FST)  exercises.  There  were  three  major  steps  to  the 
methodology  of  this  research.  First,  a  task  analysis  of  P-3  pucksters  was  conducted  by 
interviewing  subject  matter  experts  and  observing  training  exercises.  Next,  the  proper 
mode  of  interfacing  with  JSAF  was  determined  by  weighing  the  pros  and  cons  of  several 
methods.  Finally,  an  adaptive  sonobuoy  placement  behavior  was  developed  and 
implemented  in  JSAF.  The  behavior  was  successfully  implemented  in  a  local  JSAF 
terminal  and  preliminary  tests  showed  a  significant  potential  for  reducing  the  workload  of 
JSAF  operators.  It  is  recommended  that  the  adaptive  sonobuoy  behavior  be  fully 
developed  and  implemented  in  JSAF  and  this  methodology  be  used  to  automate  further 
behaviors  in  JSAF,  which  will  lead  to  reduced  manning  requirements  for  FST  exercises. 
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I.  INTRODUCTION 


Recent  budget  cuts  across  the  board  in  the  Department  of  Defense  (DoD)  have 
forced  the  Navy  to  consider  more  cost-efficient  methods  for  training  the  fleet  than  those 
currently  employed.  The  most  realistic  training  involves  the  coordination  of  several 
platforms  in  their  natural  operating  environment.  This  type  of  training  is  expensive  due  to 
the  expenditure  of  fuel  and  consumables  while  the  ships  are  underway.  For  example,  one 
day’s  worth  of  fuel  for  a  surface  combatant  costs  at  least  $40,000  (Yardley  et  al.,  2008). 
One  way  to  reduce  the  cost  of  training  and  still  maintain  a  sufficient  level  of  realism  and 
training  value  is  through  the  use  of  simulations.  Simulations  can  range  in  complexity 
from  a  single-person  laptop  program  to  a  complex  networked  virtual  environment. 

The  use  of  simulations  for  training  also  has  its  own  set  of  problems.  Many 
simulations  have  simulated  entities  with  varying  levels  of  automated  behavior  built  in.  In 
many  cases  a  human  operator  will  have  to  provide  some  control  of  the  simulated  entities 
to  ensure  their  behaviors  accurately  represent  the  actions  of  real-world  entities.  There  are 
some  cases  where  the  operator  providing  the  simulation  controls  is  not  specifically 
trained  in  the  tactics  or  behaviors  of  the  entities  they  are  controlling  or  they  may  have 
limited  training  and  experience  with  the  simulation  system  being  operated.  The  challenge 
for  any  training  simulation  is  to  minimize  the  amount  of  human  input  required  to  operate 
the  system  while  still  maintaining  realistic  behaviors. 

One  particular  area  where  simulation  is  used  extensively  is  Fleet  Synthetic 
Training  (FST).  The  Navy  Continuous  Training  Environment  (NCTE)  is  the  system  used 
to  support  FST  events,  among  other  uses.  NCTE  is  a  vital  part  of  fleet  training,  but  it  is 
becoming  more  expensive  and  operationally  infeasible  to  conduct  large-scale  fleet 
exercises.  Joint  Semi-Automated  Forces  (JSAF)  is  the  primary  simulation  engine 
incorporated  into  NCTE,  although  a  given  exercise  consists  of  a  large  federation  of 
virtual  and  constructive  simulations  and  crews  participating  from  combat  stations  aboard 
participating  vessels. 
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JSAF  can  represent  military  operations  at  the  entity  level  and  can  communicate 
with  real-world  C4I  systems.  An  FST  event  requires  several  support  staff  to  manage  and 
operate  JSAF  terminals  for  simulating  the  entities  needed  for  training.  Each  JSAF 
terminal  operator  (“puckster”)  adds  cost  to  the  training  exercise.  In  a  recent  exercise,  17 
personnel  were  used  to  simulate  P-3C  Orion  Multi-Mission  Aircraft  (MMA)  operations 
alone,  with  the  possibility  of  needing  more  in  some  circumstances. 

To  minimize  the  task  demand  on  the  P-3  pucksters  and  ultimately  reduce  the 
number  required  for  FST  exercises  while  providing  accurate  and  realistic  behaviors,  the 
following  research  questions  must  be  answered:  1)  What  are  the  cognitive  processes  and 
physical  actions  a  simulation  operator  must  complete  when  controlling  P-3  behaviors  in 
the  NCTE?  2)  What  is  the  most  efficient  input/output  method  for  communicating 
between  automation  software  and  the  P-3  simulation?  and  3)  Can  the  task  demand  of  P-3 
simulation  operators  be  reduced  enough  to  lower  the  number  of  personnel  required  to  run 
the  simulation  by  providing  software  that  automates  some  of  the  tasks  that  are  normally 
performed  by  the  operators?  The  first  two  questions  are  secondary  research  questions, 
which  will  inform  the  methods  for  answering  the  third  question,  which  is  the  primary 
research  question  for  this  study. 

To  reduce  the  number  of  pucksters  required  to  simulate  P-3  behaviors  is  the 
ultimate  goal  of  this  research.  To  accomplish  this  goal,  an  analysis  of  JSAF  terminal 
operators  responsible  for  simulating  P-3  operations  was  conducted  to  determine  the 
behaviors  that  should  be  automated  to  give  the  most  savings  in  workload.  Next,  the  best 
method  of  input  and  output  with  the  JSAF  software  was  determined,  followed  by  the 
development  of  software  to  automate  P-3  behaviors.  An  adaptive  sonobuoy  placement 
behavior  was  developed  that  shows  potential  for  a  significant  reduction  in  operator 
workload.  This  research  provides  a  methodology  for  developing  automated  behaviors  in 
JSAF  to  reduce  the  task  demand  on  P-3  pucksters  and  lead  to  a  reduction  in  the  number 
of  operators  required  for  FST  exercises,  thereby  reducing  cost  and  manpower 
requirements  for  the  Navy.  This  methodology  can  be  applied  to  develop  further  behaviors 
to  help  reduce  the  number  of  operators  required  to  simulate  other  types  of  platforms  in 
JSAF  to  help  NWDC  meet  their  budget  demands. 
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II.  BACKGROUND 


A.  FLEET  SYNTHETIC  TRAINING 

The  Fleet  Synthetic  Training  system  is  a  live,  virtual,  and  constructive  simulation 
system  used  for  Navy,  Joint  and  Partner  Nation  training.  It  consists  of  simulated  entities, 
personnel  operating  simulated  equipment  in  various  trainers,  and  operation  of  actual 
shipboard  equipment  that  is  linked  to  the  virtual  environment.  FST  is  based  on  the 
concept  of  distributed  “integrated  training,”  which  allows  units  to  connect  from  pier  side 
or  their  home  base  with  the  training  audience  connected  across  their  Areas  of 
Responsibility  (AORs)  (Wentz,  2010). 

An  example  of  how  actual  units,  simulated  entities  and  headquarters  might  be  set 
up  for  a  typical  FST  exercise  is  shown  in  Figure  1.  Many  levels  of  training  can  be 
accommodated  with  FST.  Training  can  be  at  the  unit,  multi-unit,  staff,  multi-service, 
bilateral,  or  multi-national  level  (Wentz,  2010).  A  series  of  training  events  can  provide 
warfare  proficiency  training,  interoperability  training,  operational  training,  mission 
rehearsal  training,  and  joint  operability  training  (Jay,  2008).  FST  can  accommodate 
training  for  at  least  a  portion  of  their  mission  sets  for  nearly  all  warfare  areas  required  of 
Navy,  joint  and  coalition  participants  (Jay,  2008). 

Several  simulation  and  network  architectures  are  used  to  accomplish  this 
complicated  training  task.  The  primary  systems  used  for  FST  are  the  Joint  Training  and 
Experimentation  Network  (JTEN)  and  the  Navy  Continuous  Training  Environment 
(NCTE).  The  JTEN  provides  network  connectivity  between  joint  and  coalition  forces 
and  the  NCTE  provides  the  Navy’s  network  portal  to  the  network  of  joint  training 
simulations. 

The  advantage  of  FST  is  that  it  optimizes  the  mix  of  live  and  synthetic  training, 
which  allows  for  adequate  live  training  while  leveraging  the  benefits  of  synthetic  training 
to  the  maximum  extent  possible  (Jay,  2008).  It  is  also  the  primary  means  to  integrate 
geographically-dispersed  naval,  joint  and  coalition  forces  by  utilizing  shore -based  and 
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ship-embedded  simulation  systems  linked  by  distributed  global  networks  (Jay,  2008). 
Studies  have  shown  that  fleet  readiness  increases  as  restrictions  to  training  decrease  and 
as  more  training  technology  becomes  available  (Wentz,  2010).  FST  uses  cutting  edge 
technology  to  provide  for  a  broader  scope  of  training,  which  raises  the  readiness  level  of 
the  fleet  while  minimizing  the  impact  on  the  Navy’s  budget. 


Figure  1.  Fleet  Synthetic  Training  Diagram  (From  Wentz,  2010) 


1.  NCTE 

The  Navy  Continuous  Training  Environment  (NCTE)  is  a  robust  high-speed, 
switched  IP  network  of  simulation  systems  operated  by  Naval  Warfare  Development 
Command  (NWDC).  The  network  is  designed  to  provide  reliable  bandwidth  for  24/7 
sustained  training  operations.  As  shown  in  Figure  2,  the  NCTE  links  geographically- 
separated  training  centers,  operational  commands,  and  coalition  partners  and  incorporates 
them  into  a  common  synthetic  environment. 

NCTE  is  a  global-network  infrastructure  and  integrated-communications 
enterprise  designed  and  maintained  by  the  NWDC  modeling  and  simulation  directorate 
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(Quick,  2011).  It  is  capable  of  providing  a  complete  simulation  environment 
encompassing  the  complete  battle  space  with  all  of  its  dynamic  systems,  physical  models, 
and  environmental  factors  (Quick,  2011).  NCTE  also  delivers  real-time  voice  and 
command  and  control  among  distributed  participants.  It  has  the  ability  to  host  multiple 
training,  exercise,  experimentation,  wargaming  or  concept  development  events 
simultaneously.  Events  may  be  sponsored  by  a  number  of  organizations,  including  (but 
not  limited  to)  the  Chief  of  Naval  Operations,  U.S.  Fleet  Forces  Command,  and  the 
Office  of  Naval  Research  (Quick,  201 1). 


Navy  Continuous  Training 
Environment  (NCTE) 


Figure  2.  NCTE  Connectivity  Diagram  (From  Wentz,  2010) 

One  example  of  the  value  of  the  NCTE  can  be  seen  in  training  for  Ballistic 
Missile  Defense  (BMD).  There  is  no  capability  to  train  for  BMD  in  a  live  environment. 
By  using  the  NCTE  and  accompanying  simulations  the  threat  of  ballistic  missiles  can  be 
realistically  simulated,  allowing  the  crews  of  platforms  and  the  command  element  to  train 
on  BMD  scenarios  using  their  actual  equipment,  which  is  connected  to  a  virtual 
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environment.  There  are  other  instances  of  extreme  situations  that  cannot  be  safely 
emulated  with  live  training  that  can  be  modeled  in  the  NCTE,  making  it  a  vital  part  of  the 
fleet  training  program. 

The  NCTE  is  the  world’s  largest  and  most  reliable  simulation  network  (Quick, 
2011).  The  network  has  connections  with  all  fleet  concentration  areas,  all  naval  air 
stations  with  air  simulators,  and  a  growing  number  of  multi-national  coalition  forces 
(Quick,  2011).  The  relevance  of  synthetic  training  is  increasing  each  year  due  to  the 
shrinking  DoD  budget.  According  to  NWDC’s  Modeling  and  Simulation  (M&S)  deputy 
director  Darrel  Morben,  “The  requests  for  exercises  and  experiments  are  increasing  with 
more  than  350  synthetic  events  planned  for  NCTE  next  year”  (Quick,  2011). 

2.  JSAF 

Joint  Semi-Automated  Forces  (JSAF)  is  the  entity  level  simulation  system  that  is 
the  backbone  of  the  synthetic  environment  provided  by  the  NCTE.  JSAF  generates  joint- 
service  military,  opposition  forces,  and  civilian  platforms  (vehicles,  people,  and  systems) 
that  operate  within  and  respond  to  a  synthetic  environment.  It  can  operate  in  a  stand¬ 
alone  mode  or  as  part  of  a  suite  of  simulation  systems  to  provide  input  to  various 
command  and  control  systems  in  training,  exercise,  or  experimental  settings  (Naval 
Warfare  Development  Command,  2011). 

The  core  program  libraries  for  JSAF  are  maintained  by  NWDC.  The  JSAF  source 
code  has  over  1200  libraries  and  2  million  lines  of  code.  The  primary  programming 
language  for  JSAF  is  C++  and  it  operates  under  a  Finux  operating  system.  JSAF  is  High 
Fevel  Architecture  (HFA)  compliant  and  communicates  physical  battlefield  state  and 
events  using  the  HFA  Run-Time  Infrastructure  (RTI).  The  JSAF  software  libraries, 
which  are  maintained  by  NWDC,  are  tailored  to  meet  the  needs  of  the  Navy  and  joint 
training  communities  and  are  in  compliance  with  the  NCTE  standards  4.0  (Naval  Warfare 
Development  Command,  2011). 


6 


a.  JSAF  Models 


JSAF  models  can  represent  vehicles,  units,  life  forms  and  structures  and 
are  characterized  by  three  categories  of  information,  which  are  physical  characteristics, 
performance  characteristics,  and  behaviors.  Physical  characteristics  are  necessary  for  an 
entity  that  will  have  a  visual  appearance  in  the  simulation.  There  is  a  standard  set  of 
physical  parameters  such  as  width,  length,  height,  draft,  collision  width,  and  lethal  range. 
In  some  cases,  if  there  are  components  that  affect  the  size  of  the  entity,  such  as  gun 
turrets,  they  will  be  included  as  part  of  the  entity  physical  description  (Naval  Warfare 
Development  Command,  2011).  Performance  characteristics  define  the  basic  capabilities 
of  entities  and  are  defined  in  reader  files  containing  their  parameters.  These 
characteristics  include  consumption  rates,  movement  capabilities  at  different  speeds  and 
terrains,  and  damage  models.  Entity  components,  such  as  weapons,  sensors,  and 
communications  systems  are  also  included  in  the  performance  characteristics  of  an  entity. 
Behaviors  are  a  set  of  tasks  that  the  operator  can  assign  to  an  entity  platform,  which  are 
tailored  to  the  vehicle  type  and  normal  mission.  The  idea  for  behaviors  is  that  an  operator 
can  assign  a  task,  for  example  “Deploy  Sonobuoys,”  and  the  entity  will  follow  standard 
doctrine  to  complete  the  task  with  minimal  input  from  the  operator.  The  realism  and 
complexity  of  the  behaviors  varies  among  the  entity  types  available  in  JSAF. 

The  JSAF  models  are  designed  to  operate  in  a  synthetic  environment  that 
is  networked  with  geographically  dispersed  simulation  centers  and  training  units  via  the 
NCTE.  The  synthetic  environment  is  created  by  a  compact  terrain  database  (CTDB)  with 
terrain  that  is  based  on  real  world  mapping  containing  information  such  as  altitude/depth, 
soil  type,  grade,  and  buildings  (Naval  Warfare  Development  Command,  2011).  Some 
terrain  features  can  be  “dynamic”  and  may  change  based  on  events  occurring  in  the 
simulation,  such  as  bombs  detonating,  or  features  could  temporarily  be  changed  based  on 
operator  inputs  to  the  system.  JSAF  entities  are  also  affected  by  the  weather  and  ocean 
conditions  in  the  simulation,  which  are  provided  by  either  JSAF  environmental  models  or 
real  weather/simulated  real  weather  data  from  other  simulation  systems  or  weather 
systems  (Naval  Warfare  Development  Command,  2011). 
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b.  JSAF  Displays 


There  are  two  primary  displays  used  by  the  JSAF  operator  to  interact  with 
entities  and  the  simulation  environment,  the  Plan  View  Display  (PVD)  and  the  Sea 
Combat  Commander  Display  (SCCD).  The  PVD  provides  a  complete  picture  of  the 
current  simulation  for  the  operator  by  displaying  the  “ground  truth”  of  all  friendly  and 
enemy  force  entities  in  the  simulation.  The  operator  may  not  be  able  to  control  all  entities 
visible  on  the  PVD  depending  on  the  Command  and  Control  (C2)  permissions  level  of 
the  station.  A  sample  view  of  the  PVD  is  shown  in  Figure  3. 
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Figure  3.  JSAF  Plan  View  Display 


The  SCCD  is  the  display  primarily  used  by  the  JSAF  operators 
coordinating  with  role  players  in  the  simulation  exercise.  The  role  players,  also  known  as 
Liaison  Officers  (LNO),  act  as  entity,  group,  or  task  force  commanders  for  the  simulated 
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entities  to  bridge  the  gap  between  the  training  audience  and  the  JSAF  operators.  The 
SCCD  only  displays  entities  that  are  under  the  control  of  a  particular  station  as  well  as  the 
platforms  or  entities  that  are  held  by  friendly  sensors.  The  control  of  entities  is 
determined  by  the  C2  permission  group  of  each  station.  For  example,  one  station’s  C2 
permission  group  might  be  Root.Blue.Air.MPA,  which  means  that  the  station  has  control 
of  all  blue  force  Maritime  Patrol  Aircraft  (MPA)  platforms.  The  JSAF  developers  intend 
for  the  SCCD  to  be  the  primary  display  used  by  JSAF  operators  since  it  shows  only  the 
information  that  would  be  available  to  a  mission  commander. 

The  standard  setup  for  the  display  on  the  SCCD  has  three  panels  as  shown 
in  Figure  4,  the  geographic  map  in  the  center,  the  platforms  panel  on  the  left,  and  the 
platform  control  panel  on  the  right.  There  is  also  a  menu  bar  along  the  top  to  provide 
access  to  display  and  simulation  control  functions. 
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Figure  4.  JSAF  Sea  Combat  Commander  Display  (From  Naval  Warfare  Development 

Command,  2011) 
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In  the  example  shown  in  Figure  4,  an  Arleigh  Burke  Destroyer  platform 
has  been  created  and  selected  by  the  operator.  The  map  panel  displays  platform  icons, 
platform  markings,  maneuvering  information,  and  sensor  detections  for  the  selected 
platform  (Naval  Warfare  Development  Command,  2011).  There  are  tool  icons  just  below 
the  map  area  to  allow  map  and  overlay  control.  The  left  hand  panel  has  a  platform  list  at 
the  top  as  well  as  parameters  for  the  currently  selected  platform  and  contact  information 
for  sensed  targets  in  the  bottom  section.  The  panel  on  the  right  provides  maneuvering, 
weapons,  and  sensor  controls  for  the  selected  platform. 

B.  ANTISUBMARINE  WARFARE 

1.  P-3C  Orion  Multi-Mission  Aircraft 

The  P-3C  Orion  is  a  land-based  four-engine  turboprop  anti-submarine  and 
maritime  surveillance  aircraft  used  by  the  U.S.  Navy  since  1969.  The  P-3C  Orion  was 
originally  designed  as  a  long-range  anti-submarine  warfare  (ASW)  patrol  aircraft,  but  its 
mission  has  evolved  to  include  surveillance  of  the  battlespace  over  sea  or  land  (United 
States  Navy,  2009).  The  P-3C  Orion,  built  by  Lockheed  Martin  Aeronautical  Systems 
Company,  has  four  Allison  T-56-A-14  turboprop  engines,  each  with  4600  horsepower 
(United  States  Navy,  2009).  The  operational  characteristics  of  the  P-3C  Orion  are  listed 
in  Table  1. 
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Length 

116.7  feet 

Height 

33.7  feet 

Wingspan 

99.6  feet 

Unit  Cost 

$36  million 

Weight 

Maximum  Takeoff,  139,760  pounds 

Airspeed 

Maximum,  411  knots;  Cmise,  328  knots 

Ceiling 

28,300  feet 

Range 

Mission  Radius,  2,380  nautical  miles;  3  hours 

on  station  at  1500  feet,  1346  nautical  miles 

Table  1.  P-3C  Orion  Operating  Characteristics  (After  United  States  Navy,  2009) 

The  current  mission  set  of  the  P-3C  Orion  Multi-Mission  Aircraft  includes  Anti- 
Submarine  Warfare  (ASW),  Anti-Surface  Warfare  (SUW),  Strike,  and  Intelligence, 
Surveillance,  and  Reconnaissance  (ISR).  Completion  of  these  missions  requires  a  highly 
trained  crew,  high  tech  sensors  and  equipment,  and  various  weapons. 

The  P-3C  Orion  is  manned  by  a  crew  of  11,  consisting  of  five  officers  and  six 
enlisted  personnel.  Three  naval  aviators  (pilots)  and  two  naval  flight  officers  (NFO)  make 
up  the  officer  compliment  of  the  crew.  One  NFO  is  the  Tactical  Coordinator  (TACCO), 
who  is  responsible  for  employing  tactics  and  procedures  and  coordinating  use  of  all 
sensors  for  each  type  of  mission  (Jorgenson,  1991).  The  other  NFO  is  the 
Navigator/Communicator  (NAV/COMM),  who  navigates  the  aircraft,  monitors  position 
and  navigation  systems,  and  conducts  tactical  communications  (Jorgenson,  1991).  The 
enlisted  crew  of  the  P-3C  Orion  is  as  follows:  two  flight  engineers  (FE),  responsible  to 
the  pilots  for  monitoring  engine  and  system  flight  station  controls  and  indicators;  two 
acoustic  operators,  responsible  to  detect,  localize,  classify,  track,  and  report  contact 
information  gained  by  sonobuoys  to  the  crew;  one  in-flight  technician  (IFT),  who  repairs 
damaged  or  broken  equipment  and  assists  the  TACCO  in  deployment  of  ordinance;  and 
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one  electronic  warfare  operator  (EWO),  who  utilizes  various  sensor  systems  and 
subsystems,  as  directed  by  the  TACCO,  and  detects  and  analyzes  targets  of  operational 
significance  (Jorgenson,  1991).  The  layout  of  the  P-3C  Orion  with  crew  seating  positions 
is  shown  in  Figure  5. 


NON  ACOUSTIC  (HtRATOd  NAV  raw'll  STATION 

STATION 


Figure  5.  P-3  Orion  Aircrew  Seat  Positions  (From  Jorgenson,  1991) 

The  P-3C  Orion  aircraft  must  employ  a  variety  of  sensors  and  equipment  to 
complete  the  set  of  missions  for  which  it  is  designed.  An  example  of  the  sensors  that 
would  be  used  for  ASW  operations  is  depicted  in  Figure  6.  The  sensors  of  the  P-3C  Orion 
can  be  divided  into  acoustic  and  non-acoustic  sensors  (Jorgenson,  1991).  The  acoustic 
sensors  are  operated  by  the  acoustic  operator  and  the  non-acoustic  sensors  are  operated 
by  the  EWO  (Jorgenson,  1991). 
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ASW  Sensors 


Figure  6.  P-3  ASW  Sensors  (From  Jorgenson,  1991) 


The  acoustic  sensor  of  the  P-3C  Orion  is  the  Single  Advanced  Signal  Processor 
(SASP).  To  detect  submerged  contacts  the  P-3C  Orion  can  deploy  different  types  of 
sonobuoys  to  detect  sound  waves  in  the  water.  The  SASP  processes  the  acoustic  data 
transmitted  from  the  sonobuoys  deployed  by  the  aircraft  (Jorgenson,  1991).  The  acoustic 
data  is  then  displayed  for  the  acoustic  operators  to  analyze. 

The  non-acoustic  sensors  include  the  APS-115  or  APS-137  radar,  the  ASQ-81 
magnetic  anomaly  detection  (MAD)  system,  the  AAS-36  infrared  detecting  set  (IRDS), 
and  the  APR -66  electronic  support  measures  (ESM)  system.  The  radar  is  a  vital  sensor 
for  the  operation  of  the  aircraft  for  both  tactical  and  navigation  purposes.  It  can  be  used  to 
observe  and  detect  surface  vessels,  submarines  operating  at  periscope  depth,  aircraft,  and 
other  objects  of  military  significance  (Jorgenson,  1991).  The  radar  is  also  a  critical 
component  for  flight  safety  with  weather  and  terrain  avoidance.  The  APS-137  radar  is 
found  on  the  Anti-Surface  Warfare  Improvement  Program  (AIP)  version  of  the  P-3  and  is 
more  advanced  than  the  APS-115  radar  found  on  standard  P-3  aircraft  (Jorgenson,  1991). 
The  MAD  sensor  senses  anomalies  in  the  Earth’s  magnetic  field  caused  by  a  submarine 
using  a  helium  magnetometer.  It  is  used  to  correlate  sonobuoy  detections  to  confirm  the 
location  of  a  submarine.  The  IRDS  converts  infrared  radiation  emanating  from  a  heat 
source,  such  as  a  diesel  submarine  recharging  its  batteries  on  the  surface,  to  allow  the  P-3 
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operators  to  view  targets  if  there  is  low  visibility  or  at  night  (Jorgenson,  1991).  The  ESM 
system  is  used  to  identify  electronic  emissions  from  a  submarine  by  passively  scanning 
the  radio  frequency  spectrum  for  intentional  electronic  transmissions.  The  system  can  be 
used  to  initially  determine  a  bearing  to  a  contact  and  eventually  can  triangulate  the 
contact’s  position  if  it  continues  to  radiate  (Jorgenson,  1991).  The  acoustic  and  non¬ 
acoustic  sensors  available  on  the  P-3C  Orion  aircraft  allow  the  crew  to  operate  as  a  team 
to  detect  and  track  a  submarine  whether  it  is  submerged  or  operating  on  the  surface. 

The  P-3C  Orion  is  equipped  with  different  types  of  offensive  weapons  to 
prosecute  an  enemy  submarine  once  it  is  detected  and  identified.  “The  primary  weapons 
used  against  submarines  are  torpedoes,  mines,  and  bombs”  (Jorgensen,  1991).  Table  2 
shows  the  various  types  of  weapons  typically  carried  by  a  P-3C  Orion,  although  the 
number  carried  may  vary  depending  on  the  mission  to  which  the  aircraft  is  assigned. 


Weapon 

Type 

Number  Carried 

Note: 

Mk-46 

Torpedo 

8 

N/A 

Mk-50 

Torpedo 

6 

Upgrade  from  Mk-46 

Mk-20  Rockeye 

Cluster  Bomb 

10 

247  bomblets 

AGM-65  Maverick 

Missile 

4 

IR  weapon 

AGM-84  Harpoon 

SUW  Weapon 

6 

All  weather  anti-ship  missile 

AGM-84E 

Missile 

4 

Long-range,  precision  cruise 
missile 

The  Orion  carries  various  types  of  bombs 

The  Orion  carries  various  types  of  mines 

The  Orion  carries  various  types  of  flares  and  rockets 

Table  2.  P-3C  Weapon  Payload  (From  Jorgenson,  1991) 


In  addition  to  offensive  weapons,  the  P-3C  Orion  has  the  ability  to  protect  itself 
against  an  air-to-air  missile  threat.  The  AN/AAR-47  missile-warning  set  (MWS)  will 
detect  radiation  associated  with  a  rocket  motor  of  an  incoming  missile  and  signal  the 
aircrew  of  the  incoming  missile  and  the  direction  of  the  threat  by  sector  or  quadrant 
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(Jorgenson,  1991).  The  signal  will  also  be  sent  to  the  AN/ALE-39  countermeasures 
dispensing  system  (CMDS).  The  CMDS  will  then  disperse  60  passive  radar  decoy 
cartridges  or  infrared  decoy  cartridges  (Jorgenson,  1991).  The  radar  decoys  or  chaff  are 
designed  to  confuse  the  radar  of  the  incoming  missile  and  the  infrared  decoys  or  flares 
are  for  diverting  heat  seeking  missiles. 

2.  Sonobuoys 

The  U.S.  Navy  uses  several  different  types  of  sonobuoys  for  tracking  submarines, 
collecting  oceanographic  data  and  conducting  underwater  communication.  All  of  the 
sonobuoys  used  by  P-3’s  are  standard  A-size  of  length  36  inches  and  diameter  4  7/8 
inches  and  can  be  launched  from  A-size  tubes  via  pneumatics,  free  fall,  or  a  Cartridge 
Actuated  Device  (CAD).  They  are  powered  by  “either  salt  water  activated  magnesium  or 
silver  chloride,  lithium  chemistry,  or  thermal  batteries”  (United  States  Navy,  1998).  The 
sonobuoys  have  a  deployable  acoustic  signal  source  and  reception  of  underwater  signals 
of  interest  which  are  transmitted  to  any  monitoring  unit(s),  such  as  MMAs,  helos,  or 
surface  ships  involved  in  ASW  operations. 

The  conditions  of  the  underwater  environment  can  be  monitored  by 
Bathythermograph  (BT)  Sonobuoys  and  Low  Frequency  Analysis  and  Recording 
(LOFAR)  Sonobuoys.  The  AN/SSQ-36  BT  Sonobuoy  is  used  to  provide  a  thermal 
gradient  measurement  of  the  local  water  column  to  the  monitoring  unit  (United  States 
Navy,  1998).  The  AN/SSQ-57B  LOFAR  Sonobuoy  is  used  to  accurately  measure 
ambient  noise  and  can  provide  Sound  Pressure  Level  (SPL)  measurements  (United  States 
Navy,  1998).  The  use  of  these  buoys  gives  the  aircrew  of  the  P-3  valuable  information 
about  the  local  ocean  environment,  which  helps  guide  their  selection  of  tactics. 

The  P-3C  Orion  can  send  a  message  to  a  friendly  submarine  using  a  Data  Link 
Communications  (DLC)  Sonobuoy.  The  AN/SSQ-86  DLC  Sonobuoy  can  be  encoded  by 
the  aircrew  prior  to  flight  and  provides  limited,  one-way  acoustic  communications  to 
friendly  submarines  (United  States  Navy,  1998). 

To  track  a  submarine  the  P-3C  Orion  can  use  either  passive  or  active  tactics. 

Active  tactics  are  not  used  as  frequently  due  the  possibility  of  alerting  the  submarine  to 
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the  fact  that  it  is  being  tracked.  There  are  a  variety  of  active  sonobuoys,  but  the  most 
commonly  used  is  the  AN/SSQ-62E  Directional  Command  Activated  Sonobuoy  System 
(DICASS)  Sonobuoy.  It  provides  “active  sonar  range,  bearing,  and  Doppler  information 
on  a  submerged  contact”  (United  States  Navy,  1998). 

The  primary  method  for  tracking  submerged  contacts  is  the  use  of  passive 
sonobuoys.  The  passive  buoy  most  used  is  the  AN/SSQ-53F  Directional  Frequency 
Analysis  and  Recording  (DIFAR)  Sonobuoy  shown  in  Figure  7.  The  AN/SSQ-53F 
“combines  a  passive  directional  and  calibrated  wide  band  omni  capability  into  a  single 
multi-functional  sonobuoy”  (Sonobuoy  Tech  Systems,  2008).  The  AN/SSQ-53F 
Sonobuoy  can  operate  in  one  of  three  acoustic  sensor  modes.  A  Constant  Shallow  Omni 
(CSO)  sensor  provides  acoustic  information  at  a  fixed  depth.  The  Calibrated  Omni  (CO) 
and  DIFAR  sensor  modes  allow  operation  at  a  selectable  operational  depth.  “The  buoy 
amplifies  the  underwater  acoustics  and  provides  directional  data  necessary  to  establish 
bearing  to  the  source  of  the  acoustic  energy”  (Sonobuoy  Tech  Systems,  2008). 

The  settings  of  the  AN/SSQ-53F  can  be  adjusted  prior  to  loading  and  launching 
using  Electronic  Function  Select  (EFS)  or  after  the  buoy  is  deployed  in  the  water  with 
Command  Function  Select  (CFS).  The  EFS  selectable  settings  include  Radio  Frequency 
(RF)  Channel,  Buoy  Fife,  Depth,  Sensor,  and  Automatic  Gain  Control  (AGC)  level.  Once 
the  buoy  is  deployed,  the  RF  Channel,  Buoy  Fife,  Sensor  and  AGC  level  settings  can  be 
changed  via  CFS  (Sonobuoy  Tech  Systems,  2008).  There  are  96  RF  channels  to  allow 
each  buoy  deployed  to  operate  on  a  separate  frequency,  which  is  transmitted  to  the 
monitoring  unit(s)  with  a  1  Watt  transmitter  to  an  UHF,  single  channel  command 
receiver.  The  buoy  operating  life  can  be  set  to  0.5,  1.0,  2.0,  4.0  or  8.0  hours  and  there  are 
four  depth  settings  of  90,  200,  400,  or  1000  feet  (Sonobuoy  Tech  Systems,  2008). 
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Figure  7.  AN/SSQ-53F  DIFAR  Passive  Sonobuoy  (From  Sonobuoy  Tech  Systems, 

2008) 


3.  Tactics 

The  aircrew  of  the  P-3C  Orion  Multi-Mission  Aircraft  must  apply  proper  tactics 
to  use  the  sensors  and  equipment  onboard  to  detect  and  track  enemy  submarines.  The 
tactics  can  be  broken  down  into  categories  of  acoustic  and  non-acoustic  tactics 
(Jorgenson,  1991). 

The  P-3C  Orion  uses  the  SASP  to  process  signals  from  deployed  sonobuoys  to 
track  diesel  and  nuclear  submarines.  The  P-3  will  typically  deploy  sonobuoys  based  on 
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some  sort  of  cueing  data  such  as  detection  from  another  sensor  on  the  aircraft  or  a 
position  report  from  another  naval  platform  (Jorgenson,  1991).  Once  cueing  data  is 
obtained,  the  aircrew  of  the  P-3  will  lay  down  an  organized  deployment  of  sonobuoys  in 
the  vicinity  of  the  datum  position,  which  is  called  a  sonobuoy  pattern  (Jorgenson,  1991). 
There  are  different  patterns  depending  on  the  conditions  of  the  ocean  environment  and 
the  type  of  submarine  being  tracked  with  a  specified  geometry  and  spacing  between 
buoys  that  will  optimize  the  probability  of  detecting  a  submarine.  The  spacing  and  pattern 
of  the  sonobuoys  is  important  because  the  P-3  has  a  limited  number  of  sonobuoys  and  the 
detection  range  to  the  submarine  could  be  only  a  few  hundred  yards  (Jorgenson,  1991). 

If  a  submarine  is  detected  by  one  or  more  of  the  deployed  sonobuoys  the  P-3 
acoustic  operators  will  analyze  the  broadband  and  narrowband  noise  signature  of  the 
submarine,  with  the  help  of  the  SASP,  to  attempt  to  determine  the  submarine’s  identity. 
“Once  the  submarine  has  been  classified,  it  is  the  goal  of  the  crew  to  maintain  “contact” 
with  the  submarine”  (Jorgenson,  1991).  The  crew  will  figure  out  the  course  and  speed  of 
the  submarine  and  deploy  sonobuoys  along  the  track  of  the  submarine  to  help  maintain 
contact.  The  crew  will  have  to  be  alert  to  any  changes  in  course  or  speed  the  submarine 
makes  to  maintain  contact. 

There  are  several  non-acoustic  sensors  available  to  the  aircrew  of  the  P-3C  Orion 
to  supplement  the  acoustic  sensors  to  detect  an  enemy  submarine,  particularly  if  it  is 
operating  on  the  surface  or  at  periscope  depth.  The  APS-115  or  APS-137  radar  can  detect 
surfaced  submarines  or  exposed  periscopes  or  snorkels.  The  submarine  can  use  its  ESM 
equipment  to  detect  the  radar  from  a  P-3  and  may  submerge  to  avoid  detection.  The  radar 
can  detect  a  periscope  at  distances  exceeding  10  miles,  but  the  radar  is  not  capable  of 
classifying  a  submarine  so  another  sensor  is  needed  to  corroborate  the  radar  return 
(Jorgenson,  1991). 

The  IRDS,  MAD,  and  ESM  sensor  systems  are  used  to  provide  additional 
detection  information  about  a  submarine  to  help  corroborate  a  radar  return.  The  IRDS  is 
used  to  detect  the  heat  caused  by  a  submarine  operating  near  the  surface,  particularly  if 
the  submarine  is  a  diesel  recharging  its  batteries  (Jorgenson,  1991).  The  MAD  sensor  is 

used  to  detect  magnetic  anomalies  in  the  water  and  its  effectiveness  is  determined  by  the 
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altitude  of  the  aircraft  and  the  depth  of  the  submarine.  A  low  altitude  pass  directly  over  a 
shallow  submarine  will  provide  the  best  opportunity  of  receiving  a  “MAD  Hit”  due  to 
minimizing  the  slant  range  to  the  target.  The  MAD  sensor  may  be  susceptible  to  false 
detections  from  things  like  seamounts  or  shipwrecks  when  operating  in  shallow  water 
environments  (Jorgenson,  1991).  The  ALR-66  ESM  system  is  capable  of  detecting 
electronic  emissions  from  a  submarine,  such  as  radar  or  radio  transmissions.  The  ESM 
can  provide  a  bearing  to  the  transmission  source  and  can  be  used  to  analyze  the 
parameters  of  the  emissions  to  identify  the  type  of  radar  being  used  (Jorgenson,  1991). 
The  crew  of  the  P-3C  Orion  has  the  training  and  expertise  to  use  all  of  the  sensors 
available  to  detect  a  submarine  and  confirm  its  identity  and  continue  to  track  it  as  it 
transits  through  the  water. 

C.  FINITE  STATE  AUTOMATA 

Many  agent  based  simulations,  such  as  JSAF,  use  finite  state  automata  as  the 
formalism  that  structures  the  behaviors  of  entities  in  the  simulation.  Each  entity  in  JSAF 
has  different  types  of  behaviors  that  act  as  a  finite  state  automaton  (or  machine),  which  is 
“a  device  that  can  be  in  a  finite  number  of  states”  (Daciuk,  1998).  The  device  will  switch 
between  states  if  the  proper  conditions  are  met  in  the  simulation.  The  switching  of  states 
is  called  a  transition  (Daciuk,  1998).  The  finite  state  machine  can  be  represented  in 
different  ways  such  as  directed  graphs,  state  diagrams,  or  tables.  Figure  8  shows  a 
directed  graph  representation  of  a  finite  state  automaton. 
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Figure  8.  Sample  Finite  State  Automaton  (From  Daciuck,  1998) 


In  Figure  8,  each  circle  represents  a  possible  state  of  the  finite  state  automaton. 
The  states  with  double  circles  are  final  states  and  state  A  is  the  initial  state  denoted  by  the 
arrow  from  the  left  with  nothing  at  its  origin  (Daciuk,  1998).  The  arrows  between  states 
represent  state  transitions  with  labels  denoting  the  input  required  to  cause  the  state 
transition  to  occur.  The  set  of  inputs  that  may  be  accepted  by  the  automaton  is  called  the 
“language”  (Daciuk,  1998)  of  that  particular  automaton.  For  an  input  to  be  accepted  the 
automaton  would  have  to  be  able  to  transition  from  the  initial  state  to  one  of  the  final 
states.  The  automaton  depicted  in  Figure  8  accepts  the  language  \c,  a,  ac,  ae,  be}  with  e 
denoting  an  empty  input,  which  would  be  accepted  since  A  is  a  final  state.  Inputs  such  as 
bd  or  af  would  be  rejected  since  E  is  not  a  final  state  (Daciuk,  1998). 

Finite  state  automata  have  many  uses  in  today’s  computing  industry.  They  are 
used  for  language  processing  algorithms,  control  of  transducers,  image  storage  and 
recognition,  engineering  systems,  and  artificial  intelligence  applications.  The  entities  in 
JSAF  have  different  types  of  behaviors,  which  are  controlled  by  finite  state  machines.  For 
example,  the  behavior  of  a  P-3C  Orion  to  deploy  sonobuoys  is  controlled  by  a  finite  state 
machine  shown  in  Figure  9. 
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D.  MENTAL  SIMULATION 

When  a  person  is  tasked  with  performing  an  operation  that  is  complex  or  not 
routine  they  will  frequently  use  a  technique  called  “mental  simulation”  to  help  them 
envision  the  sequence  of  actions  required  to  accomplish  the  operation.  Gary  Klein,  who 
has  studied  the  way  people  make  decisions  for  several  years,  describes  mental  simulation 
as  “the  ability  to  imagine  people  and  objects  consciously  and  to  transform  those  people 
and  objects  through  several  transitions,  finally  picturing  them  in  a  different  way  than  at 
the  start”  (1998).  Before  attempting  to  automate  a  task  that  may  be  performed  by  a  JSAF 
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operator  it  is  important  to  know  how  the  operator  might  use  mental  simulation  to 
determine  the  sequence  of  actions  for  the  task. 

When  reviewing  several  cases  where  mental  simulation  was  applied  Gary  Klein 
found  some  general  similarities  among  mental  simulations.  They  follow  the  same  basic 
pattern:  there  is  a  starting  point,  a  sequence  of  inputs,  actions  and  outputs,  and  a  final 
state  or  goal  condition  (Klein,  1998).  Mental  simulations  are  limited  in  complexity  due  to 
limits  of  human  memory  so  they  generally  consist  of  three  or  less  moving  parts  and  six  or 
less  steps  (or  transition  states)  (Klein,  1998).  There  are  techniques  to  get  around  the 
limitations  on  the  number  of  moving  parts  and  steps  such  as  grouping  several  actions  or 
parts  together  or  using  writing  out  of  steps  or  diagrams  to  help  with  the  mental 
simulation,  but  even  diagrams  can  get  complicated  quickly  and  become  difficult  to  follow 
(Klein,  1998).  The  more  knowledgeable  a  person  is  in  the  subject  of  the  simulation,  the 
more  complex  the  mental  simulation  can  be. 

A  generic  model  of  a  mental  simulation  is  shown  in  Figure  10.  As  shown,  the 
person  conducting  the  mental  simulation  first  determines  if  they  are  trying  to  explain  the 
past  or  project  into  the  future.  Once  this  is  determined,  the  initial  state,  and  final  desired 
state  are  determined  and  causal  factors  are  identified.  The  person  performing  the 
simulation  then  constructs  a  sequence  of  actions  to  transition  from  the  initial  state  to  the 
final  state  and  evaluates  the  sequence  “for  coherence  (Does  it  make  sense?),  applicability 
(Will  I  get  what  I  need?),  and  completeness  (Does  it  include  too  much  or  too  little?)” 
(Klein,  1998).  If  there  are  any  issues  the  person  can  reassess  at  the  appropriate  step. 
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Figure  10.  Generic  Model  of  Mental  Simulation  (After  Klein,  1998) 


Mental  simulation  is  a  powerful  tool  for  decision  making  in  complex  operations 
and  is  a  likely  mental  model  that  would  be  used  by  a  JSAF  operator  during  a  naval 
exercise.  The  mental  simulation  constructed  by  a  JSAF  operator  for  conducting  a 
particular  task  or  mission  can  be  used  as  the  template  for  constructing  an  algorithm  for 
automating  behaviors  of  the  P-3C  Orion  aircraft. 
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III.  CURRENT  EFFORTS  IN  SIMULATION  AUTOMATION 


There  are  several  examples  of  efforts  to  produce  realistic  entity  behaviors  in 
military  simulations  to  help  reduce  the  need  for  pucksters  and  provide  quality  training. 
Virtual  Puckster  is  designed  to  provide  “behavior  generation  for  Army  small  team 
training  and  mission  rehearsal”  (Colonna-Romano  et  al.,  2009).  Discovery  Machine  and 
EasyCog  both  attempt  to  provide  improvements  to  JSAF  behaviors.  Discovery  Machine 
provides  an  interface  to  allow  subject  matter  experts  (SMEs)  to  combine  modular  basic- 
level  actions  (BLAs)  to  develop  a  more  complex  behavior  (Potts  et  al.,  2010).  The 
purpose  of  EasyCog  is  to  provide  a  “software  solution  that  automatically  generates 
realistic  behavior  of  friendly,  hostile,  neutral,  or  environmental  entities  in  simulation” 
(Weyhrauch,  2010),  particularly  for  Fleet  Synthetic  Training.  These  three  technologies 
were  chosen  to  study  due  to  the  similarity  of  the  problem  they  are  trying  to  solve  to  the 
problem  of  this  thesis  and  because  they  each  have  a  unique  approach  to  solving  the 
problem  of  entity  behavior  automation. 

A.  DISCOVERY  MACHINE 

The  United  States  military  has  come  to  rely  more  on  the  use  of  simulation  than  in 
the  past  due  to  shrinking  DoD  budgets.  Large  scale  training  exercises  can  require 
simulation  of  several  autonomous  and  semi-autonomous  entities  that  must  “behave  in 
well-defined  ways  that  correctly  mimic  their  real-world  counterparts”  (Potts  et  al.,  2010). 
Proper  behaviors  can  help  ensure  training  goals  are  met  and  prevent  negative  training  due 
to  unrealistic  behavior  from  the  simulated  entities  (Potts  et  al.,  2010). 

Discovery  Machine  Inc.  has  created  a  “behavior  modeling  framework  for 
constructive  entities  which  enables  subject  matter  experts  (SMEs)  to  develop  complex 
entity  behaviors  using  modular  basic-level  actions  (BLAs)  through  an  easy  to  use  wizard¬ 
like  interface”  (Potts  et  al.,  2010).  They  have  developed  behaviors  for  constructive 
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entities  in  JSAF  for  submarines,  surface  ships  and  rotary  wing  aircraft,  and  modeled 
behaviors  of  non-player  characters  in  the  Irregular  Warfare  Virtual  Trainer  for  Joint 
Forces  Command. 

Discovery  Machine  provides  GUIs  known  as  behavior  model  authoring  consoles 
for  the  SME  to  use  while  creating  behaviors.  The  bulk  of  the  work  for  creating  behaviors 
for  Discovery  Machine  is  spent  in  the  programming  of  BLAs.  Once  these  are  created  a 
SME  can  create  a  mission  or  set  of  behaviors  using  BLAs  “with  no  software  engineering 
expertise  in  a  matter  of  minutes”  (Potts  et  al.,  2010).  The  behaviors  developed  by  SMEs 
can  then  be  sent  to  a  simulation,  such  as  JSAF,  without  having  to  touch  the  simulation 
source  code  through  an  interface  layer  as  shown  in  Figure  11. 


Figure  11.  Discovery  Machine  High  Level  System  Architecture  (After  Potts  et  al., 

2010) 

Once  a  behavior  is  built  in  Discovery  Machine,  operators  can  visually  trace  the 
execution  of  the  behavior  at  runtime  in  a  hierarchical  view  as  shown  in  Figure  12.  This 
allows  operators  and  instructors  to  see  the  steps  the  behavior  must  go  through  and  helps 
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understanding  of  why  entities  are  performing  particular  actions  (Discovery  Machine, 
2010).  The  advantages  of  this  feature  are  that  it  “facilitates  the  improvement  of  behaviors 
and  reduces  frustration  when  entities  behave  in  an  unexpected  manner”  (Discovery 
Machine,  2010). 


Discovery  Machine  has  conducted  validation  testing  of  its  surface  ship  behaviors 
in  JSAF  using  a  scenario  with  60+  entities  controlled  by  their  behavior  models 
(Discovery  Machine,  2010).  Without  the  Discovery  Machine  behaviors  running,  three 
operators  were  required  to  control  JSAF  entities  and  they  were  focused  on  the  tasking  80 
to  100%  of  the  time  during  the  test.  When  the  same  scenario  was  run  with  Discovery 
Machine  behaviors  running  only  one  operator  was  required  and  was  focused 
approximately  50%  of  the  time  to  monitor  the  controlled  entities.  This  shows  an  effective 
reduction  in  workload  by  the  JSAF  operators  by  at  least  a  factor  of  five  (Discovery 
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Machine,  2010).  Discovery  Machine  Inc  has  shown  that  its  behavior  development 
software  can  help  reduce  operator  workload  by  providing  automated  entity  behaviors. 

There  are  several  advantages  to  the  Discovery  Machine  Inc  behavior  modeling 
framework.  It  allows  subject  matter  experts  to  develop  behaviors  with  no  software 
knowledge  required,  which  helps  ensure  the  behaviors  provide  realistic  representation  of 
real-world  entities.  It  has  a  hierarchal  behavior  visualization  tool,  which  provides  a  way 
to  debug  behaviors  without  programming.  Finally,  it  has  proven  that  it  can  reduce  the 
workload  of  operators  and  allow  simulation  exercises  to  be  run  with  fewer  operators 
while  still  meeting  training  objectives.  There  are,  however,  some  drawbacks  to  the 
Discover  Machine  software.  Running  Discovery  Machine  in  the  JSAF  environment 
requires  hardware  to  be  connected  to  each  machine  at  which  JSAF  entities  are  controlled. 
Each  hardware  setup  costs  between  $2000-3000  and  there  are  over  70  stations  for 
controlling  JSAF  entities  during  a  major  training  exercise.  Additionally,  the  Discover 
Machine  software  is  not  owned  by  NWDC  so  they  do  not  have  the  ability  to  perform 
upgrades  or  maintenance  on  the  behavior  code  as  required  for  changes  in  tactics  or  other 
real-world  changes. 

B.  VIRTUAL  PUCKSTER 

Recently,  there  has  been  a  shift  in  the  way  the  Army  fights,  from  large  force-on- 
force  engagements  to  asymmetric  operations,  often  in  urban  environments  involving 
smaller  groups  such  as  platoons  or  squads  (Colonna-Romano  et  al.,  2009).  This  has  led  to 
a  change  in  the  “Army’s  requirements  for  training  and  mission  rehearsal  exercises  in 
deployed  environments”  (Colonna-Romano  et  al.,  2009).  Current  synthetic  exercise 
training  tools  for  the  Army  require  several  pucksters  and  do  not  have  the  level  of  detail 
required  to  simulate  coordinated  actions  of  small  teams. 

Virtual  Puckster  is  a  project  in  development  to  help  improve  Army  small  team 
training  and  mission  rehearsal.  It  is  a  Phase  II  Small  Business  Innovative  Research 
project  developed  by  Aptima  and  Total  Immersion  Software.  Specifically,  Virtual 
Puckster  is  an  “application  that  will  allow  intuitive,  real-time  control  of  small  groups  of 
synthetic  forces,  that  will  offload  the  human  puckster  from  the  details  of  the  coordination 
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of  group  behaviors,  and  that  will  allow  the  puckster  to  make  rapid  adjustments  to  team 
behavior  as  circumstances  dictate”  (Colonna-Romano  et  al.,  2009).  The  Virtual  Puckster 
system,  shown  in  Figure  13,  “consists  of  a  graphical  user  interface  (GUI),  Group 
Behavior  Engine  (GBE)  and  a  Group  Behavior  ‘Play’  library”  (Colonna-Romano  et  al., 
2009). 


Virtual  Puckster 
Puckster  GUI 

Group  Behavior 
Engine 

Play 

Library 


Figure  13.  Virtual  Puckster  System  (From  Colonna-Romano  et  al.,  2009) 

The  operator  controls  the  Virtual  Puckster  system  through  the  GUI  by  selecting 
the  play  that  is  appropriate  for  the  training  scenario.  The  puckster  can  provide  inputs  to 
the  system  to  adjust  the  behavior  from  the  GBE  to  tailor  it  to  the  conditions  of  the 
scenario.  The  adjustment  to  the  play  can  be  made  real-time  when  “unexpected 
developments  arise,  such  as  surprising  trainee  behavior  or  equipment  failure”  (Colonna- 
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Romano  et  al.,  2009).  The  benefit  of  Virtual  Puckster  is  that  it  allows  for  control  of  a 
small  team  training  simulation  by  one  operator  who  is  an  expert  in  the  training  domain, 
but  not  necessarily  the  simulation.  It  also  removes  some  of  the  burden  from  the  puckster 
by  providing  behaviors  for  the  small  team  while  the  puckster  focuses  on  controls  for  only 
key  members  of  the  team. 

C.  EASYCOG 

To  help  reduce  the  number  of  human  operators,  or  “pucksters”  required  to  run  a 
JSAF  simulation  and  improve  the  quality  of  training  conducted  using  JSAF,  Charles 
River  Analytics  Inc.  is  developing  a  software  solution  called  EasyCog.  The  purpose  of 
EasyCog  is  to  “automatically  generate  realistic  behavior  of  friendly,  hostile,  neutral,  or 
environmental  entities  in  simulation”  (Weyhrauch,  2010).  The  behaviors  modeled  by 
EasyCog  will  be  adaptable  to  various  conditions  and  able  to  react  to  changes  in  the 
simulation  environment  or  actions  of  trainees  using  the  simulation,  therefore,  they  will 
require  minimum  human  intervention.  EasyCog  behaviors  are  designed  to  be  reusable 
and  adjustable  to  the  training  level  required  for  a  given  exercise.  The  features, 
advantages,  and  benefits  of  the  EasyCog  software  are  summarized  in  Table  3. 


Feature 

Advantage 

Benefit 

Autonomous  behavior 

Human  pucksters  do  not 
need  to  micromanage 
behavior 

Cost  savings  by  limiting 
need  for  human  pucksters 

Sound  psychological  and 
science-based  realistic, 
human  behavior 

Behavior  exhibits  subtlety 
of  human  behavior  under 
combat  or  stressful 
conditions 

Training  more  realistic; 
enemies  provide  actual 
challenge 

Modules  and  components 

Model  components  can  be 
built  once  and  reused  many 
times 

Cost  savings  on  model 
development  and 
maintenance 

Models  of  human 
performance  and  learning 

System  can  support 
intelligent  tutoring,  after 
action  review,  and  multiple 
levels  of  behavior 
complexity 

Training  can  be  tailored  to 
expertise  of  trainee, 
maximizing  the  value  of 
limited  training  time 

Table  3.  EasyCog  Features,  Advantages  and  Benefits  (From  Weyhrauch,  2010) 
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EasyCog  has  many  features  that  could  make  it  an  ideal  solution  to  reducing  the 
number  of  operators  required  to  simulate  entities  in  JSAF,  however,  it  is  still  in  the  early 
stages  of  development.  In  September  2012,  EasyCog  will  be  ready  to  demonstrate 
feasibility  for  Fleet  Synthetic  Training,  which  will  be  assessed  by  customers  and  subject 
matter  experts.  Then  there  will  be  another  year  before  they  are  ready  for  a  live  program 
demonstration.  The  problem  addressed  by  this  research  is  limited  to  the  automation  of 
Multi-Mission  Aircraft  and  will  require  a  solution  prior  to  the  full  development  of 
EasyCog. 
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IV.  METHODOLOGY 


After  completing  the  literature  review  the  next  step  is  to  attempt  to  answer  the 
research  questions  for  this  study.  There  are  three  major  steps  of  the  methodology  for 
answering  the  three  research  questions.  The  first  step  is  to  conduct  an  analysis  of  the 
operations  conducted  by  JSAF  operators  to  answer  the  first  research  question  and  to 
decide  which  behavior  to  automate.  The  next  step  is  to  investigate  possible  interfaces 
with  the  JSAF  simulation  system  to  answer  the  second  question.  The  final  step  is  to 
develop  the  automated  P-3  task,  which  involves  scoping  and  describing  the  task,  solving 
the  geometry  of  the  problem  and  testing  it  with  a  prototype  program,  and  finally 
implementing  the  task  in  JSAF.  A  test  of  the  behavior  is  then  conducted  to  evaluate  the 
ability  to  reduce  operator  workload. 

A.  TASK  ANALYSIS  OF  P-3  PUCKSTERS 

Before  producing  automation  software  for  P-3C  Orion  behaviors  it  is  necessary  to 
know  how  a  P-3C  Orion  performs  its  mission  as  well  as  how  a  JSAF  operator  performs 
the  task  of  simulating  the  aircraft.  The  first  step  of  learning  the  process  of  both  of  these 
tasks  is  conducting  a  detailed  literature  review  of  the  P-3C  Orion  Multi-Mission  Aircraft 
and  the  JSAF  simulation  system,  which  is  summarized  in  chapter  2  of  this  thesis.  The 
next  step  is  to  conduct  interviews  with  SMEs  and  observe  the  operation  of  simulation 
operators  while  they  are  simulating  P-3  operations  for  an  actual  naval  training  exercise. 
Once  this  is  completed,  it  can  be  determined  which  tasks  require  the  most  attention  from 
the  operators  and  can  be  automated  in  JSAF  using  the  mental  simulation  approach. 

Two  trips  were  conducted  to  visit  the  Naval  Warfare  Development  Command 
(NWDC)  in  Norfolk,  VA  for  information  gathering.  The  purpose  of  the  first  trip  was  to 
tour  the  facility,  speak  with  JSAF  and  P-3  subject  matter  experts  about  the  operation  of 
JSAF  for  simulation  exercises,  and  observe  demonstrations  of  P-3s  being  simulated  in 
JSAF.  The  second  trip  was  to  observe  actual  JSAF  operators  controlling  P-3s  for  the 
TERMINAL  FURY  training  exercise. 
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1. 


Facilities AYorking  Environment  of  JSAF  Operators 


The  NWDC  site  in  Norfolk,  VA  is  a  secure  site  where  JSAF  is  maintained  and 
operated  for  FST  events.  There  are  office  areas  for  programmers,  administrators  and 
managerial  staff,  but  the  primary  operation  of  JSAF  is  conducted  in  the  main  operational 
center.  There  are  JSAF  terminals  arranged  in  concentric  circles  around  a  central  control 
station  where  the  referees  of  the  simulation  coordinate  the  event.  For  a  given  event  the 
terminals  are  grouped  according  to  the  type  of  platform  being  controlled.  For  example,  all 
of  the  friendly  force  MMA  stations  will  be  in  close  proximity  to  each  other  and  the 
enemy  submarine  stations  will  be  in  a  separate  area. 

Each  JSAF  terminal  is  equipped  with  two  flat  screen  monitors,  a  mouse  and  a 
keyboard  for  the  JSAF  operator  and  a  similar  setup  for  the  Liaison  Officer  (LNO)  who 
acts  as  a  buffer  between  the  operator  and  the  training  audience  of  the  exercise.  There  are 
also  secure  and  non-secure  phones  for  every  few  terminals  for  communicating  with  other 
JSAF  terminals  of  with  personnel  involved  in  the  exercise  in  other  geographic  areas. 
Each  operator  has  a  comfortable  chair  and  ample  desk  space  for  notebooks  and  other 
papers  as  necessary. 

Exercises  will  typically  run  for  several  days  with  a  day  or  two  of  familiarization 
time  for  the  operators.  Once  the  exercise  is  commenced  the  operators  and  LNO’s  will 
work  12  hour  shifts  with  12  hours  off  until  completion  of  the  exercise.  Operators  will 
typically  bring  food  with  them  for  meals  during  their  shift  and  eat  at  their  station  while 
continuing  to  control  the  P-3s  under  their  cognizance. 

The  amount  of  attention  required  of  the  operators  varies  throughout  the  exercise. 
The  operators  are  responsible  for  launching  the  P-3s,  conducting  any  tasking  they  are 
assigned,  and  returning  the  P-3s  to  their  operating  base.  The  launch  times  are  staggered 
so  the  operators  have  to  be  continually  aware  of  the  time  until  the  next  aircraft  launch  or 
return  to  base.  Typical  tasking  consists  of  patrolling  an  area  for  high  value  unit 
protection,  deploying  sonobuoys  to  search  for  a  submarine,  and  tracking  and/or  attacking 
a  submarine.  If  any  of  these  tasks  occur  while  other  P-3s  need  to  take  off  or  land  it  can  be 
easy  for  the  JSAF  operator  to  become  distracted  and  not  complete  a  task  on  time.  While 
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one  individual  task  may  not  be  particularly  taxing  on  an  operator,  they  need  to  be 
constantly  vigilant  of  the  status  of  all  aircraft  under  their  control. 

2.  JSAF  Operators  Training  and  Qualifications 

JSAF  Operator  and  LNO  positions  are  manned  from  various  sources  for  FST 
exercises.  The  JSAF  operators  consist  of  personnel  from  NWDC,  some  of  whom  are 
SME’s  on  the  platform  they  are  simulating  and  some  who  are  JSAF  programmers  with  no 
platform  specific  experience,  and  other  civilians  who  typically  have  previous  military 
experience.  The  majority  of  the  LNO’s  are  manned  from  the  reserves  and  are  0-3s  or  O- 
4s  from  the  community  being  simulated. 

Prior  to  the  commencement  of  the  exercise  the  operators  and  LNO’s  are  briefed 
on  the  scenario  and  training  objectives  of  the  exercise  and  given  time  to  familiarize 
themselves  with  the  JSAF  interface  and  practice  tasks  with  their  platforms,  such  as 
creating  and  launching  a  P-3  or  laying  down  a  sonobuoy  pattern.  There  is  no  training 
given  on  specific  tactics  for  a  certain  platform,  but  tactical  manuals  are  available  to 
reference  for  a  particular  tactic.  The  operators  may  also  be  provided  with  “knee  boards” 
to  give  them  guidance  on  tactics.  For  example,  a  P-3  knee  board  would  provide  the  basic 
steps  and  settings  for  deploying  a  sonobuoy  pattern,  such  as  buoy  spacing,  depth  setting, 
and  pattern  selection. 

There  is  a  noticeable  learning  curve  for  the  coordination  between  the  exercise 
referees,  the  LNO’s  and  the  JSAL  operators.  The  assignment  of  aircraft  to  operators  is 
made  by  the  LNO’s  and  initially  does  not  follow  any  sensible  scheme  such  as  assigning 
aircraft  by  similar  mission  types  or  the  same  geographic  operating  area.  It  was  unclear 
who  was  responsible  for  creating  overlays  of  P-3  operating  areas  in  JSAL,  which  are 
assigned  in  the  Air  Tasking  Order  (ATO).  It  also  took  a  shift  or  two  for  the  operators  to 
develop  a  good  system  for  keeping  track  of  the  timing  and  tasking  of  their  aircraft.  There 
is  always  at  least  one  operator  per  shift  who  is  a  SME  on  the  platform  to  provide  backup 
and  guidance  if  a  situation  requires  a  special  tactic. 
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Overall,  there  is  not  much  formal  training  for  JSAF  operators.  They  primarily 
learn  from  on-the-job  experience  during  exercises  or  from  the  shared  experience  and 
training  that  other  operators  and  LNO’s  have  from  past  exercises  or  military  service. 

3.  Communications 

There  are  several  methods  and  paths  of  communication  required  to  make  a  FST 
event  a  success.  This  research  primarily  focuses  on  the  role  of  the  JSAF  operators  who 
communicate  with  their  LNO’s  and  other  JSAF  operators  in  their  vicinity.  Therefore, 
only  the  communication  methods  of  JSAF  operators  and  LNO’s  will  be  described  below. 

The  tasking  for  Multi-Mission  Aircraft  comes  from  two  main  sources.  The  ATO 
provides  the  timing  and  mission  areas  and  types  for  all  MMA  flights.  The  ATO  is  in  the 
form  of  a  spreadsheet  that  lists  the  call  sign,  aircraft  type,  mission  area,  mission  type, 
operating  base  and  times  of  takeoff,  on  station,  off  station  and  return  to  base  for  each 
aircraft.  Any  deviation  from  the  ATO  will  be  communicated  to  the  LNO  via  chat 
message  from  the  task  force  commander.  The  LNOs  are  responsible  for  managing  the 
assignment  of  missions  to  the  JSAF  operators.  The  operators  receive  a  sheet  of  paper 
from  their  LNO  for  each  mission  for  which  they  are  responsible.  The  paper  will  have  all 
pertinent  times  for  the  mission,  a  description  of  the  tasking,  load  out  information  for 
sonobuoys  and  weapons  and  an  area  for  recording  comments  during  the  mission.  If  new 
tasking  is  assigned,  such  as  direction  to  track  a  possible  submarine  based  on  intelligence 
reports,  the  LNO  will  write  down  the  tasking  on  a  post-it  note  and  pass  it  to  the 
appropriate  operator  who  will  in  turn  update  his  tasking  sheet  and  execute  the  new 
tasking. 

The  JSAF  operators  make  several  standard  reports  to  the  LNO’s  throughout  the 
exercise.  They  report  when  P-3’s  are  on  station  and  off  station  and  report  information 
regarding  detection  and  engagement  of  hostile  submarines.  When  a  submarine  is  detected 
the  JSAF  operator  generates  a  “nine  line”  report,  which  has  the  contact  type,  track 
number,  confidence  level,  sensor  position,  sensor  type,  contact  position,  contact 
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course/speed,  date-time  group  and  any  amplifying  remarks.  The  LNO  receives  the  nine- 
line  report  and  relays  the  information  to  the  Combined  Task  Force  (CTF)  commander  in 
charge  of  the  exercise  via  MS  chat. 

Operators  primarily  rely  on  face  to  face  communication  with  nearby  operators  and 
their  LNO.  They  may  also  communicate  with  more  distant  JSAF  terminals  via  phone  or 
e-mail,  or  have  the  LNO  contact  the  CTF  headquarters  over  the  secure  phone  or  with 
Voice  over  Internet  Protocol  (VoIP).  There  are  occasions  when  a  surface  ship  JSAF 
operator  will  gain  contact  on  a  hostile  submarine  and  the  MMA  operators  will  be 
informed  of  the  submarine  by  the  other  operators,  but  will  not  receive  tasking  to  track  the 
submarine  for  up  to  20  minutes  due  to  the  time  to  inform  the  CTF  and  for  the  order  to  be 
passed  to  the  LNO  from  the  CTF. 

When  a  P-3  has  completed  its  mission  and  returned  to  its  home  base  the  JSAF 
operator  passes  the  sheet  for  the  P-3  to  a  station  where  the  data  is  entered  into  a  database 
to  keep  a  narrative  of  the  entire  exercise.  Additionally  the  LNO  informs  the  CTF  via  chat 
when  the  P-3  completes  its  mission.  Another  communication  method  available  is  Link 
16,  which  is  a  military  tactical  data  network.  This  network  allows  platforms  to  share  a 
common  tactical  operational  picture  and  can  be  used  to  exchange  text  messages  or 
photographic  images.  The  SCCD  has  a  Link  Management  View  window  to  create  and 
send  Link  16  messages,  but  this  is  seldom  used  by  JSAF  operators. 

The  predominant  mode  of  communication  for  JSAF  operators  is  face  to  face 
communications  with  information  also  being  exchanged  on  paper  and  via  chat  as 
secondary  means  of  communication.  The  verbal  communications  are  not  formal  in  nature 
and  do  not  adhere  to  any  known  communication  standard  such  as  a  ship’s  communication 
manual. 

4.  Operation  of  JSAF  Terminals 

The  primary  duty  of  the  JSAF  operator  is  to  provide  realistic  behaviors  for 

simulated  entities  in  JSAF,  which  are  reflected  in  the  NCTE  for  FST  exercises.  The 

operator  controls  entities  using  JSAF  in  the  SCCD  mode  or  the  PVD  mode.  Both  modes 

are  typically  displayed  and  have  similar  functionality.  The  SCCD  is  a  newer  interface  and 
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was  designed  to  be  more  user  friendly  to  ease  the  burden  on  the  JSAF  operators, 
however,  some  operators  with  previous  experience  using  the  PVD  will  rarely  use  the 
SCCD  for  controlling  entities. 

The  main  difference  between  the  SCCD  and  the  PVD  is  the  level  of  situational 
awareness  they  provide  to  the  JSAF  operator.  The  SCCD  only  shows  platforms 
controlled  by  that  console  or  contacts  sensed  by  their  platform  or  fed  into  the  common 
operational  picture  (COP)  by  other  platforms  in  the  exercise.  The  PVD  shows  ground 
truth  data  for  all  entities  in  the  exercise  regardless  of  which  station  is  controlling  them. 
This  means  the  operator  will  have  more  information  available  when  using  the  PVD,  but 
the  SCCD  is  more  realistic  because  it  only  shows  information  that  would  actually  be 
available  to  the  crew  of  the  platform.  Since  the  SCCD  is  meant  to  be  the  primary  means 
for  controlling  entities  in  JSAF  this  research  will  focus  on  SCCD  operation. 

The  JSAF  operator  controls  the  SCCD  using  a  mouse,  keyboard  and  monitor  for 
all  input  and  output  functions.  The  first  step  is  to  create  an  entity  using  the  Platform 
Creation/Entity  Selection  section  of  the  SCCD  shown  in  Figure  14.  The  operator  selects 
the  “New”  tab  at  the  top  and  finds  the  desired  entity  using  one  of  the  filters  available. 
Most  operators  use  the  marking  filter  and  just  start  typing  the  name  of  the  entity  and  the 
list  is  filtered  similar  to  a  word  search  program.  Once  the  entity  is  displayed  on  the  screen 
the  user  selects  it  by  left  clicking  the  mouse. 
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My  Platforms  New 

New  Unit _ 

Unit  Report  AIS  IFF 


Figure  14.  Platform  Creation/Entity  Selection  Panel  of  the  SCCD  (From  Naval 

Warfare  Development  Command,  2011) 

The  operator  then  proceeds  to  the  Platform  Creation,  Specifics  and  Position 
Selection  panel  in  the  bottom  left  of  the  SCCD  screen  as  shown  in  Figure  15.  In  this 
panel  the  operator  fills  in  the  “Call  Sign,”  “Mission  ID”  and  “ATO  ID”  fields  as 
necessary  and  specifies  the  position  where  the  entity  will  be  created  by  typing  in  the 
latitude  and  longitude  or  by  selecting  on  the  map  area  using  the  map  tool  (globe  and 
sextant).  Next  the  altitude  or  depth  is  specified  and  the  orientation  (course)  of  the  entity  is 
filled  in  and  the  operator  left  clicks  the  “Create”  button  to  finish  creation  of  the  entity. 
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Figure  15.  Platform  Creation,  Specifics  and  Position  Selection  Panel  of  the  SCCD 
(From  Naval  Warfare  Development  Command,  2011) 


Once  an  entity  is  created,  the  JSAF  operator  assigns  a  task  to  the  entity  related  to 
the  completion  of  its  mission.  In  the  case  of  P-3  operations  for  TERMINAL  FURY,  the 
operator  first  has  the  P-3  transit  to  its  assigned  operating  area.  If  the  assigned  mission  is 
to  search  the  area  for  submarines  the  operator  uses  the  SCC  Maneuver  Panel  in  the  top 
right  comer  of  the  SCCD  screen  shown  in  Figure  16  to  make  the  P-3  deploy  a  sonobuoy 
search  pattern  in  its  assigned  area.  When  the  “New  Task”  button  is  clicked  a  drop  down 
menu  appears  with  the  tasks  available  for  the  platform  selected.  The  operator  selects  the 
“Deploy  Sonobuoys”  task  from  the  menu  and  the  options  for  the  deploy  sonobuoys  task 
comes  up  as  shown  in  Figure  17. 
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Figure  16.  SCC  Maneuver  Panel 

After  the  deploy  sonobuoys  task  is  displayed  the  operator  specifies  the  parameters 
for  the  sonobuoy  pattern  to  be  deployed.  Under  “Deploy  Type,”  a  drop  down  menu 
allows  the  operator  to  choose  from  use  pattern,  along  route,  or  at  point.  Operators 
typically  choose  to  plot  a  route  using  a  line  creation  tool  or  they  may  choose  a 
preprogrammed  pattern  from  the  “Pattern”  drop  down  menu.  Next  the  operator  specifies 
the  buoy  depth  setting,  buoy  duration,  initial  RF  channel,  whether  to  increment  or 
decrement  the  RF  channel,  and  the  speed  and  altitude  of  the  aircraft.  Some  of  these 
settings  just  require  the  default  setting  to  be  used,  therefore  no  manipulation  is  necessary. 
The  JSAF  operator  then  ensures  the  “Monitor  Buoys”  box  is  checked  and  the  left  clicks 
the  “Apply”  button  to  create  the  new  task.  This  step  does  not  cause  the  task  to  be 
executed  immediately,  so  the  operator  can  set  up  the  sonobuoy  pattern  ahead  of  time 
while  the  P-3  is  transiting  to  the  operating  area. 

Further  tasking  for  the  P-3  is  handled  in  a  similar  manner  using  the  SCC 
Maneuver  Panel.  The  most  common  tasks  include  transiting  to  or  from  an  operating  area, 
deploying  sonobuoys  (individually  or  in  a  pattern),  patrolling  an  area,  and  conducting  a 
torpedo  attack  on  a  hostile  submarine.  Another  method  for  controlling  the  P-3  manually 
is  with  the  steering  wheel  tool  shown  in  Figure  18.  With  the  steering  wheel  tool  turned  on 
the  operator  can  change  the  P-3s  speed,  course,  and  altitude  by  clicking  and  dragging  on 
the  tool  that  appears  above  the  platform  graphic  in  the  map  panel  of  the  SCCD.  This  tool 
is  useful  for  maneuvering  a  P-3  into  position  for  a  torpedo  attack. 
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Figure  17.  Deploy  Sonobuoy  Task  (From  Naval  Warfare  Development  Command, 

2011) 


Figure  18.  Steering  Tool  (From  Naval  Warfare  Development  Command,  201 1) 


If  JSAF  operators  are  not  assigning  tasks  to  a  P-3  they  still  must  monitor  the 
aircraft  under  their  control  for  detection  of  enemy  platforms  and  be  cognizant  of  the  time 
until  the  next  scheduled  action.  If  a  contact  is  detected  by  one  or  more  of  the  P-3  sensors 
a  datum  icon  will  appear  in  the  map  panel  in  the  location  of  the  detection.  The  icons  have 
different  colors  and  shapes  to  indicate  if  the  contact  is  hostile,  friendly,  neutral  or 
unknown  and  to  indicate  the  contact  type,  such  as  sub-surface,  aircraft,  or  a  surface  ship. 
For  detailed  information  about  the  contact,  the  operator  can  open  the  Track  Status 
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window  shown  in  Figure  19.  The  Track  Status  window  shows  all  of  the  contacts  available 
to  the  platform  in  a  table  format,  which  is  helpful  for  generating  nine-line  reports. 
Additionally,  the  operator  can  see  some  of  the  contact  information,  such  as  course,  speed 
and  depth,  in  the  map  section  when  placing  the  mouse  over  the  datum  icon  for  a  contact. 
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Figure  19.  Track  Status  Window  of  the  SCCD  (From  Naval  Warfare  Development 

Command,  2011) 


The  SCCD  has  many  other  functions  that  are  not  used  as  frequently  by  the  JSAF 
operators.  Other  activities  the  operators  are  responsible  for  include  plotting  of  overlays  to 
indicate  operating  areas  for  their  P-3s  and  saving  the  scenario  periodically  in  case  there  is 
a  system  crash.  None  of  the  actions  performed  by  the  operators  take  very  long,  but  the 
operators  can  become  overwhelmed  or  distracted  when  controlling  several  P-3s 
simultaneously  and  tasks  start  to  pile  up  when  the  situation  is  dynamically  changing.  In 
some  cases  the  operators  will  refer  to  the  PVD  to  get  a  better  contact  picture  so  they  can 
allocate  their  attention  to  areas  with  more  activity,  such  as  an  area  with  a  hostile 
submarine  nearby. 

5.  Areas  for  Improvement 

After  speaking  to  SMEs  and  observing  JSAF  operators  conducting  a  fleet 
exercise,  several  areas  were  noted  that  could  use  improvement  and  lead  to  a  reduction  in 
the  number  of  operators  required  for  an  exercise.  There  are  issues  with  the  organization 
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of  the  exercises  and  training  of  the  JSAF  operators  as  well  as  entity  behaviors  that  could 
be  automated  to  make  the  JSAF  operator’s  job  more  efficient. 

Several  of  the  JSAF  operators  observed  were  either  unfamiliar  with  the  operation 
of  the  SCCD  or  proper  tactics  for  the  platform  they  were  controlling.  A  short  training 
session  on  the  operation  of  the  SCCD  and  P-3  tactics  implementation  in  JSAF  before  the 
start  of  the  exercise  would  be  helpful.  There  is  extensive  documentation  on  operation  of 
the  SCCD  and  P-3  tactics,  but  it  would  make  it  easier  on  the  operators  if  there  were 
condensed  guides  or  tutorials  for  them  to  refer  to  while  they  are  busy  controlling  multiple 
P-3s. 

Three  organizational  issues  were  noted  during  the  TERMINAL  FURY  exercise. 
The  JSAF  operators  were  distracted  on  several  occasions  by  having  to  produce  overlays 
for  new  operating  areas  assigned  by  tasking  messages.  Many  of  the  overlays  were  created 
in  JSAF  prior  to  the  start  of  the  exercise,  but  there  was  not  a  designated  person  for 
entering  new  areas  as  they  were  received.  Another  inefficient  practice  was  the  assignment 
of  P-3  to  the  operators.  Early  in  the  exercise  the  LNOs  were  just  randomly  assigning 
aircraft  to  the  operators  as  they  were  received  on  the  ATO.  A  scheme  for  assigning  P-3s 
was  eventually  developed,  but  it  took  more  than  an  entire  shift  to  get  the  P-3s  organized. 
Each  operator  should  only  be  assigned  P-3s  in  a  certain  geographic  area  or  mission  type, 
which  will  help  the  operator  to  focus  on  a  limited  scope  of  operations  and  help  the  team 
organization.  The  last  area  of  organization  that  needs  improvement  is  the  tracking  of 
mission  timing  by  JSAF  operators.  The  operators  used  their  mission  assignment  papers  to 
keep  track  of  the  times  for  the  next  mission  event  (take  off,  return  to  base  etc.),  with  the 
papers  in  a  pile  in  no  apparent  order.  A  timeline  program  with  a  row  for  each  mission  and 
the  event  times  annotated  would  alleviate  the  possibility  of  operators  being  late  to 
complete  events. 

Two  P-3  tasks  were  identified  that  require  a  large  amount  of  attention  from  the 
operator.  The  first  task  is  conducting  a  torpedo  attack  on  an  enemy  submarine.  This  task 
requires  the  operator  to  select  a  torpedo  from  the  weapon  inventory  or  the  P-3,  select  the 
proper  torpedo  settings  for  the  attack,  manually  guide  the  P-3  to  the  proper  course,  speed 

and  altitude  for  dropping  a  torpedo  and  then  drop  the  torpedo  with  the  correct  timing  to 
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have  a  successful  attack.  This  process  takes  a  significant  amount  of  time  and  attention  for 
the  operator  to  complete  and  it  requires  knowledge  of  the  proper  tactics  and  settings  to  be 
completed  in  a  timely  and  accurate  manner.  A  torpedo  attack  behavior  would  allow  the 
operator  to  pay  attention  to  tasking  for  other  P-3s  and  would  ensure  a  properly  executed 
attack  in  accordance  with  P-3  tactical  manuals.  The  second  task  that  should  be  automated 
is  the  placement  of  sonobuoys  to  track  a  submarine  once  it  has  been  detected  and  is 
exiting  the  sonobuoy  pattern  that  has  already  been  placed  by  the  P-3.  This  task  requires 
the  operator  to  pay  close  attention  to  the  course  and  speed  of  the  submarine  so  the 
sonobuoy  pattern  can  be  adjusted  for  changes  in  the  submarine’s  track.  It  also  requires 
accurate  placement  of  the  sonobuoys  in  complex  geometrical  patterns  using  proper 
tactics.  An  algorithm  for  placing  the  sonobuoys  would  be  more  accurate  and  realistic  and 
the  behavior  could  keep  track  of  the  submarine’s  track  and  adapt  as  required  without 
dropping  unnecessary  sonobuoys.  The  behavior  could  be  programmed  to  provide  an  alert 
to  the  operator  if  contact  is  lost  with  the  submarine  to  allow  the  operator  to  take  control 
of  the  P-3  and  regain  contact  with  the  submarine. 

Of  the  areas  mentioned  above  for  improving  the  workload  of  P-3  JSAF  operators, 
the  plotting  of  overlays,  torpedo  attack  on  a  submarine  and  sonobuoy  placement  are  the 
three  that  could  be  addressed  with  automation  software.  The  remainder  of  this  research 
will  focus  on  the  automation  of  sonobuoy  placement  for  tracking  a  submarine  for  several 
reasons.  The  sonobuoy  placement  behavior  will  have  the  greatest  impact  on  relieving  the 
workload  of  the  operators.  There  already  exists  a  task  in  JSAF  for  deploying  sonobuoys 
in  a  set  pattern  that  could  be  extended  to  adaptively  placing  sonobuoys  with  relative  ease. 
Last,  this  work  will  show  the  ability  to  automate  a  complex  task  using  the  mental 
simulation  framework  and  provide  an  example  of  the  process  for  automating  behaviors  in 
JSAF  that  can  be  repeated  for  future  behaviors. 

B.  DETERMINING  THE  BEST  JSAF  INTERFACE 

After  observing  JSAF  operators  controlling  P-3s  for  an  exercise  and  speaking 
with  SME’s  the  next  step  was  to  determine  the  best  way  to  interface  with  JSAF  to  create 
an  automated  adaptive  sonobuoy  behavior.  Based  on  literature  review  and  conversations 
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with  JSAF  programmers,  three  options  were  identified  for  implementation  of  the 
algorithm:  1)  Create  the  behavior  with  Discovery  Machine  software  and  connect  to  JSAF 
using  their  software;  2)  Use  a  standalone  program  to  run  the  algorithm  and  communicate 
with  JSAF  via  an  interface,  such  as  a  user-bot;  or  3)  Program  the  algorithm  directly  into 
the  JSAF  source  code.  Each  option  will  be  discussed  below  and  pros  and  cons  will  be 
given  for  each  approach. 

1.  Discovery  Machine 

The  Discovery  Machine  software  allows  SME’s  to  author  behaviors  for  JSAF 
entities  by  piecing  together  basic-level  actions  (BLA)  they  have  programmed.  Once  a 
behavior  is  created,  Discovery  Machine  has  a  visualization  tool  that  allows  tracing  the 
steps  executed  as  the  behavior  runs.  If  the  behavior  passes  the  checks  using  the 
visualization  tool  it  can  be  run  in  JSAF  for  testing  using  the  Discovery  Machine  interface 
layer.  Discovery  Machine  Inc.  has  an  office  in  Norfolk,  VA  and  works  closely  with  JSAF 
developers,  which  could  be  useful  if  any  problems  were  encountered  during  the  creation 
of  the  adaptive  sonobuoy  placement  behavior. 

There  are  several  advantages  to  using  the  Discovery  Machine  approach  for 
automating  P-3  behaviors.  Potts  et  al.  (2010)  list  the  following  advantages  of  the 
Discovery  Machine  Behavior  modeling  approach: 

•  Rapid  development  of  new  behaviors  for  customized  training  scenarios 

•  Expert  domain  knowledge  captured  within  the  modeling  tools  to  assist 
building  more  intelligent  behaviors 

•  Transparency  of  behaviors  for  subject  matter  experts  during  and  after 
development 

•  Transparency  of  behaviors  at  runtime,  easing  the  debugging  process  and 
exposing  decision  making  process  of  entities  to  operators 

Other  advantages  include  the  fact  that  knowledge  of  the  JSAF  source  code  would  not  be 
required  and  that  there  would  be  minimal  coding  involved  with  this  approach. 
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There  are  also  several  drawbacks  to  using  the  Discovery  Machine  software  to 
create  behaviors  for  the  P-3  aircraft  in  JSAF.  The  primary  concern  of  the  JSAF 
programmers  was  the  fact  that  they  would  not  have  proprietary  rights  to  the  code  for  the 
behavior  developed  from  this  research  if  Discovery  Machine  was  used.  Therefore,  they 
would  have  to  rely  on  Discovery  Machine  to  maintain  the  code  and  ensure  the  behavior 
was  up  to  date  with  the  latest  tactical  publications.  NWDC  would  also  have  to  pay 
approximately  $2,000  annually  for  each  terminal  that  has  the  Discovery  Machine 
software  connected.  Additionally,  the  BLA’s  for  fixed-wing  aircraft  are  not  fully 
developed  (Discovery  Machine,  2011)  so  the  project  timeline  does  not  allow  for  waiting 
for  full  development  of  the  BLA’s. 

Based  on  the  advantages  and  disadvantages  of  the  Discovery  Machine  approach, 
it  was  decided  not  to  use  this  method  for  developing  the  adaptive  sonobuoy  placement 
behavior.  However,  if  NWDC  were  to  commit  to  funding  the  connection  of  Discovery 
Machine  to  multiple  JSAF  terminals  and  Discovery  Machine  completed  the  programming 
of  fixed-wing  aircraft  BLA’s,  it  could  be  a  viable  solution  for  future  behavior 
development  efforts. 

2.  External  Program 

A  second  option  for  implementing  an  adaptive  buoy  placement  behavior  in  JSAF 
is  to  program  the  algorithm  as  stand-alone  software  and  have  it  communicate  with  JSAF 
through  an  interface.  The  interface  would  most  likely  involve  communicating  with  JSAF 
using  High  Level  Architecture  (HLA)  protocols  to  get  data  from  the  simulation  and 
provide  inputs  for  controlling  the  behavior  of  the  P-3.  Another  option  is  the  use  of  a 
userbot  to  essentially  take  control  of  the  display,  mouse  and  keyboard  of  the  JSAF 
terminal  and  perform  the  actions  that  would  be  taken  by  a  JSAF  operator  from  a  remote 
program. 

This  approach  shares  some  advantages  and  disadvantages  with  the  Discovery 
Machine  method  as  well  as  some  additional  considerations.  Similar  to  Discovery 
Machine,  this  method  would  not  require  learning  the  JSAF  source  for  behaviors,  but  the 
interface  method  would  require  some  coding,  which  could  be  extensive.  Also  in  common 
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with  Discovery  Machine  is  the  fact  that  the  program  would  be  separate  from  JSAF  so  it 
would  have  to  be  incorporated  into  the  JSAF  update  process.  However,  the  program 
would  be  owned  by  NWDC  at  the  end  of  the  project  so  they  could  make  changes  as 
desired.  Additional  advantages  to  using  a  separate  program  are  that  any  software 
language  can  be  used  for  the  algorithm  and  the  debugging  process  would  be  faster  than  if 
the  algorithm  was  coded  directly  into  the  JSAF  source  code.  The  disadvantage  is  that  a 
large  amount  of  time  would  be  spent  learning  the  interface  protocols  for  connecting  to 
JSAF  instead  of  focusing  on  behavior  automation,  which  is  the  primary  purpose  of  the 
research. 

Using  an  external  program  for  the  adaptive  sonobuoy  placement  behavior  was 
eliminated  as  an  option  after  weighing  the  benefits  and  drawbacks  of  the  approach.  The 
software  engineers  at  NWDC  expressed  their  desire  for  the  behavior  to  be  part  of  the 
JSAF  code  and  it  is  undesirable  to  spend  too  much  time  and  effort  learning  the  JSAF 
interface  protocols.  However,  an  external  program  is  used  in  the  development  of  a 
prototype  to  test  the  geometry  of  the  sonobuoy  patterns  before  implementation  in  JSAF. 

3.  Direct  Coding  in  JSAF 

The  last  option  considered  for  implementing  the  adaptive  sonobuoy  placement 
behavior  was  programming  the  behavior  directly  in  the  JSAF  source  code.  This  could  be 
achieved  by  creating  a  new  task  that  monitors  for  enemy  submarines  and  triggers  an 
adaptive  sonobuoy  placement  task,  or  by  modifying  the  existing  task  for  deploying 
sonobuoys. 

There  are  several  advantages  to  this  approach.  The  primary  consideration  is  that 
the  code  for  the  algorithm  would  be  a  part  of  JSAF  and  would  be  owned  by  NWDC  for 
updates  and  maintenance,  and  the  task  can  be  upgraded  to  mimic  classified  and  evolving 
tactics  by  NWDC.  Another  advantage  is  the  support  available  for  coding  in  JSAF.  There 
are  two  workstations  with  an  unclassified  version  of  JSAF  installed  at  the  Modeling, 
Virtual  Environments,  and  Simulation  (MOVES)  Institute  at  the  Naval  Postgraduate 
School  (NPS)  available  for  use  by  students  and  faculty.  There  are  also  personnel  at 
NWDC  working  with  NPS  to  help  with  any  coding  questions  and  to  evaluate  the 
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effectiveness  of  the  algorithm.  The  last  advantage  is  that  time  that  would  be  spent 
learning  the  interface  protocols  of  JSAF  can  be  dedicated  to  developing  and 
implementing  the  behavior  in  JSAF. 

As  with  any  technique,  there  are  some  drawbacks  to  programming  the  adaptive 
sonobuoy  behavior  directly  in  the  JSAF  source  code.  The  code  for  JSAF  is  highly 
complicated  with  approximately  1200  libraries  and  5  million  lines  of  code.  In  addition  to 
having  to  learn  a  complex  program,  there  is  no  flexibility  in  the  choice  of  program 
language  for  the  algorithm.  The  last  disadvantage  is  the  debug  cycle  time.  After  making 
an  alteration  to  the  code,  it  takes  close  to  two  minutes  to  rebuild  JSAF  and  run  a  scenario 
to  test  the  change. 

The  disadvantages  of  direct  programming  in  the  JSAF  code  mean  that  it  may  take 
longer  to  implement  the  algorithm;  however,  the  fact  that  the  code  will  be  owned  by 
NWDC  and  can  be  upgraded  to  a  classified  version  of  the  behavior  outweighs  the  time 
disadvantage.  Therefore,  the  decision  was  made  to  implement  the  adaptive  sonobuoy 
placement  behavior  by  programming  it  directly  in  the  JSAF  source  code. 

C.  P-3  TASK  AUTOMATION  DEVELOPMENT 

1.  Scope  of  the  Task 

For  the  initial  development  of  the  adaptive  sonobuoy  placement  task  the  behavior 
is  limited  in  scope  to  solving  the  basic  geometry  and  behavior  of  the  algorithm.  The  first 
implementation  of  the  behavior  will  assume  that  there  will  only  be  one  submarine  in  the 
geographical  area  to  which  the  P-3  is  assigned.  The  algorithm  will  only  account  for  the 
use  of  passive  sonobuoy s,  even  though  there  are  rare  occasions  where  active  sonobuoy s 
may  be  used.  There  are  some  cases  where  the  crew  of  the  P-3  may  decide  to  vary  the 
buoy  life  setting  on  the  deployed  sonobuoys,  but  this  will  not  be  accounted  for  in  the  first 
implementation  and  buoy  life  will  be  set  at  eight  hours.  The  assumed  environment  will  be 
open-ocean,  so  accounting  for  littoral  regions  will  be  considered  after  the  baseline 
behavior  is  solved.  If  the  P-3  has  to  track  a  submarine  for  an  extended  time  period  the 
aircraft  would  eventually  run  out  of  sonobuoys  and  another  asset  would  have  to  assume 
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the  tracking  duties  or  the  P-3  may  transition  to  another  air  asset’s  operating  area  and  turn 
over  tracking  duties.  This  scenario  will  not  be  modeled  in  the  first  behavior 
implementation. 

There  are  also  limitations  to  the  adaptive  sonobuoy  placement  behavior  due  to  the 
fact  that  the  submarine  tracking  tactics  of  the  P-3  are  classified  and  this  research  is 
unclassified.  Any  numerical  settings  for  the  initial  algorithm  will  be  approximations  of 
actual  classified  values  and  the  tracking  task  will  be  functional,  but  will  not  display  actual 
tactical  operations. 

2.  Description  of  Task 

Prior  to  implementation  of  the  adaptive  sonobuoy  placement  behavior  in  JSAF,  a 
detailed  description  of  what  the  behavior  should  look  like  and  the  steps  to  perform  the 
behavior  is  required.  An  initial  description  of  the  task  including  display  considerations, 
the  geometry  of  the  buoy  pattern,  and  the  steps  of  the  behavior  was  developed  using  the 
mental  simulation  framework  and  improvements  were  made  based  on  suggestions  of 
SME’s  at  NWDC.  The  concept  for  the  initial  behavior  implementation  is  as  follows: 

a.  Graphical  User  Interface 

•  Add  a  “Track  Hostile  Sub”  checkbox  to  the  Deploy  Sonobuoys 
task  that  already  exists  in  JSAF  as  shown  in  Figure  20. 

•  Alert  icon  in  “My  Platforms”  and  accompanying  message  in 
“Alerts”  tab  to  tell  the  operator  that  a  contact  has  been  classified  as 
a  hostile  sub. 

•  Alert  icon  and  accompanying  message  to  tell  the  operator  if 
contact  is  lost  with  the  submarine. 

•  Remove  the  route  overlay  for  the  current  sonobuoy  pattern  and  add 
the  overlay  for  the  new  route. 
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Figure  20.  Track  Hostile  Submarine  Checkbox 


b.  Deploying  Sonobuoys 

•  Get  course,  speed,  depth,  and  position  of  submarine  (based  on 
sensor  data). 

•  Get  position  of  sonobuoys  already  being  monitored  by  the  P-3. 

•  Periodically,  calculate  position  and  time  to  deploy  next  sonobuoy 
based  on  projected  submarine  course  and  speed  and  existing 
sonobuoy  field. 

•  If  a  sonobuoy  is  needed: 

•  Determine  shortest  route  to  deploy  sonobuoy. 

•  Set  sonobuoy  parameters. 

•  Position  the  P-3  to  drop  sonobuoy  (heading,  speed, 
altitude). 

•  Drop  sonobuoy  when  at  release  location. 

•  If  no  sonobuoys  are  needed: 

•  Orbit  last  sonobuoy  position  until  next  buoy  is  needed. 

When  calculating  the  position  to  drop  the  next  sonobuoy  the  program  will 
determine  the  two  closest  sonobuoys  to  the  submarine  and  then  drop  a  new  sonobuoy 
such  that  it  makes  an  equilateral  triangle,  on  the  side  the  submarine  is  traveling  towards, 
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with  the  two  existing  sonobuoys.  The  algorithm  will  check  positions  along  the 
submarine’s  track  and  check  if  a  sonobuoy  is  needed  for  each  position.  A  sonobuoy  is 
needed  at  a  certain  position  when  the  submarine  is  not  within  the  detection  range  of  less 
than  three  sonobuoys.  The  submarine  can  be  tracked  with  less  than  three  sonobuoys  in 
contact,  but  the  accuracy  of  the  cross-fix  obtained  by  three  sonobuoys  is  better. 
Therefore,  the  goal  of  the  algorithm  is  to  have  three  sonobuoys  tracking  the  submarine  at 
all  times. 

An  overhead-view  example  of  the  geometry  that  may  be  encountered 
when  implementing  the  behavior  is  shown  in  Figure  21.  In  this  illustration,  the  red  buoys 
were  deployed  by  a  P-3  based  on  an  intelligence  report  and  the  submarine  is  detected 
heading  to  the  northeast.  Based  on  the  submarine’s  course,  the  next  buoy  deployed  is  the 
green  buoy,  which  makes  an  equilateral  triangle  with  buoys  3  and  4.  Then  the  submarine 
maneuvers  to  the  northwest  and  the  algorithm  places  buoy  6  to  make  an  equilateral 
triangle  with  buoys  4  and  5. 
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Figure  21.  Geometry  for  a  Typical  Sonobuoy  Pattern  Extension 
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The  time  at  which  the  P-3  drops  a  sonobuoy  to  extend  the  pattern  is  also 
important  to  ensure  sonobuoy  inventory  is  preserved  while  still  maintaining  contact  on 
the  submarine.  If  a  sonobuoy  is  dropped  too  early  and  the  submarine  maneuvers,  the 
sonobuoy  would  then  serve  no  purpose.  Conversely,  if  the  sonobuoy  is  dropped  too  late 
there  is  a  risk  that  the  submarine  may  be  out  of  range  of  the  sonobuoy  field  and  contact 
may  be  lost.  Therefore,  the  algorithm  must  take  into  account  the  time  it  will  take  the 
submarine  to  reach  the  point  at  which  it  will  only  be  in  range  of  two  sonobuoys,  the  time 
for  the  P-3  to  transit  to  the  drop  point,  the  time  for  the  sonobuoy  to  reach  the  water  and 
the  time  for  the  sonobuoy  to  sink  to  its  ordered  depth  and  be  ready  to  detect  a  submarine. 

3.  Geometry  of  Sonobuoy  Pattern 

Once  the  algorithm  determines  the  two  sonobuoys  that  are  closest  to  the 
submarine’s  position  the  next  step  is  to  determine  the  correct  location  to  drop  the 
sonobuoy.  The  position  of  the  existing  sonobuoys  and  the  velocity  vector  of  the 
submarine  can  be  obtained  from  the  simulation  and  can  be  used  with  vector  math  and 
geometry  to  calculate  the  new  sonobuoy  position.  The  geometry  for  calculating  the  new 
sonobuoy  position  is  shown  in  Figure  22.  The  JSAF  environment  is  three  dimensional, 
therefore  each  symbol  in  Figure  22  is  a  three  dimensional  vector. 


Figure  22.  Sonobuoy  Placement  Geometry 
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The  first  step  towards  finding  the  new  sonobuoy  placement  position  b3  is  to 

calculate  the  difference  vector  between  the  two  closest  sonobuoy  positions  bx  and  b2  as 
follows: 

d  =bi  —b\ 

Next,  the  midpoint  between  the  two  closest  sonobuoy  positions  must  be  calculated 
as  follows: 

—  bi+t>2 

m  = - 

2 

The  vector  pointing  in  the  up  direction  u  can  be  obtained  from  the  simulation, 
which  will  be  described  in  the  section  for  implementing  the  behavior  in  JSAF.  The  next 

step  is  to  find  the  vector  p  that  is  perpendicular  to  both  the  up  vector  u  and  the 

difference  vector  d  .  The  vector  p  must  be  perpendicular  to  the  up  vector  to  ensure  the 
new  sonobuoy  is  in  the  same  plane  as  the  two  closest  sonobuoys.  This  does  not  account 
for  the  curvature  of  the  earth,  but  due  to  the  close  proximity  of  the  sonobuoys  the  effect  is 

insignificant.  The  vector  p  is  perpendicular  to  the  difference  vector  to  ensure  it  points  to 

the  new  sonobuoy  position.  Therefore,  the  vector  p  has  to  satisfy  the  following 
equations: 

p  ■  u  =  0 
p- d  =  0 

Since  the  vectors  are  three  dimensional,  there  are  two  equations  with  three 
unknowns  in  the  equations  above.  Only  the  direction  of  the  vector  p  is  of  significance, 
so  one  of  the  components  of  p  ,  such  as  pz ,  can  be  set  to  one  leaving  two  equations  with 
two  unknowns,  which  can  be  solved  with  simple  algebra.  Solving  the  equations  gives  the 
components  of  p  as  follows: 
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Px 


y  d' W X^'Y  J 


Py 


i/i  ^d-  x  ^z^x 
Ux  d -y  H/yd  x 


Pz  =1 


The  perpendicular  vector  p  is  converted  to  a  unit  vector  of  length  one  by  dividing 
each  component  by  the  length  of  the  vector  as  follows: 


P  = 


P_ 

P 


The  position  of  the  new  sonobuoy  could  fall  on  either  side  of  the  two 
closest  sonobuoy s  depending  on  the  course  of  the  submarine.  The  new  sonobuoy  must  be 
placed  on  the  side  the  submarine  is  traveling  toward,  which  can  be  determined 
mathematically  by  taking  the  dot  product  of  the  submarine’s  velocity  vector  v  and  the 


perpendicular  vector  p  .  If  the  dot  product  v  ■  p  is  positive  or  zero  then  the  position  of  the 
new  sonobuoy  can  be  found  as  follows: 


bi 


P 


Otherwise,  the  new  sonobuoy  will  be  placed  on  the  opposite  side  of  the  two 
closest  sonobuoys  with  its  position  calculated  as  follows: 


bi 


P 


The  adaptive  sonobuoy  placement  algorithm  will  use  this  method  for  determining  where 
to  drop  the  next  sonobuoy  once  it  has  determined  that  one  is  needed  at  some  point  along 
the  submarine’s  track.  This  technique  is  not  an  actual  Anti-Submarine  Warfare  tactic,  but 
it  does  an  adequate  job  of  maintaining  at  least  three  sonobuoys  in  contact  with  a 
submarine  regardless  of  its  course  or  speed. 
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4.  Prototype  Program 


Before  implementing  the  adaptive  sonobuoy  placement  behavior  in  JSAF, 
portions  of  the  algorithm  were  tested  using  a  prototype  program  completely  separate  from 
JSAF.  Since  JSAF  already  has  tasks  for  routing  P-3’s  to  drop  sonobuoys  this  portion  was 
not  implemented  in  the  prototype  program.  The  purpose  of  the  prototype  was  to  test  the 
geometry  of  the  sonobuoy  pattern  with  a  maneuvering  submarine  to  ensure  there  was 
adequate  sonobuoy  coverage  for  a  variety  of  submarine  maneuvering  patterns. 

There  is  a  wide  variety  of  software  available  that  would  be  suitable  for  testing  the 
algorithm.  It  was  desired  to  have  a  visual  representation  of  the  submarine  and  sonobuoy 
field  and  the  ability  to  control  the  submarine  using  mouse  and/or  keyboard  commands. 
The  software  chosen  for  creating  the  prototype  program  was  the  DarkGDK  game 
development  kit  software.  DarkGDK  uses  C++  as  its  program  language  and  is  free  of 
charge  with  Microsoft  Visual  C++  2008  Express  Edition.  This  software  was  chosen  for 
several  reasons.  First,  the  software  is  free  and  is  in  the  same  programming  language  as 
the  JSAF  source  code,  which  will  ease  the  transfer  of  the  algorithm  to  JSAF. 
Additionally,  the  software  meets  all  of  the  needs  of  the  prototype  program  and  is  easy  to 
use.  The  research  team  also  has  previous  experience  using  the  DarkGDK  toolkit,  which 
minimized  the  time  spent  learning  the  software. 

Since  the  SCCD  panel  in  JSAF  shows  an  overhead,  two-dimensional  view  of  the 
entities,  the  prototype  program  was  implemented  as  an  overhead,  two-dimensional 
representation.  Icons  for  representing  the  submarine,  existing  sonobuoys  and  newly 
placed  sonobuoys  were  created  using  Microsoft  Paint  and  coordinates  were  specified  for 
placement  of  the  submarine  and  existing  sonobuoys  in  a  pattern  similar  to  the  example  in 
Figure  21.  The  initial  setup  of  the  submarine  and  sonobuoys  for  the  prototype  program 
is  shown  in  Figure  23.  The  blue  circles  represent  the  sonobuoys  dropped  by  a  P-3  prior  to 
gaining  the  submarine  and  the  thin  black  circles  show  the  maximum  detection  range  of 
the  sonobuoys. 


56 


Figure  23.  Initial  Setup  for  Prototype  Program 


To  test  the  geometry  of  the  adaptive  sonobuoy  pattern  the  user  is  given  the  ability 
to  “drive”  the  submarine  using  the  arrow  keys  on  the  keyboard.  There  is  a  function  to 
determine  the  number  of  sonobuoys  whose  range  to  the  submarine  is  within  the 
maximum  detection  range  and  if  the  result  of  this  function  drops  below  three  to  trigger  a 
new  sonobuoy  to  be  dropped.  This  function  will  also  issue  a  warning  if  the  number  of 
sonobuoys  in  contact  with  the  submarine  drops  to  less  than  two,  which  means  the 
algorithm  is  not  performing  adequately  to  maintain  contact  with  the  submarine.  The 
placement  of  the  new  sonobuoy  is  based  on  the  geometry  described  in  section  3  of  this 
chapter. 

As  the  submarine  proceeds  on  an  easterly  course  it  will  eventually  reach  a  point 
where  it  will  only  be  in  range  of  two  rightmost  sonobuoys.  At  this  point  the  program  will 
direct  a  new  sonobuoy  to  be  dropped  such  that  an  equilateral  triangle  is  made  with  the 
two  rightmost  sonobuoys  as  shown  in  Figure  24. 
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Figure  24.  First  Extension  Sonobuoy 


As  the  submarine  continues  to  move  forward  the  algorithm  will  continue  to  drop 
new  sonobuoys  (red  circles)  to  maintain  contact  with  the  submarine.  An  example  of  the 
sonobuoy  pattern  that  would  develop  for  a  submarine  maneuvering  is  shown  in  Figure  25 . 
The  dotted  line  represents  the  path  the  submarine  followed  during  its  transit. 


Figure  25.  Extension  of  Sonobuoy  Pattern  for  a  Maneuvering  Submarine 
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The  prototype  program  was  run  under  several  conditions  to  test  the  geometry  of 
the  adaptive  sonobuoy  placement  algorithm.  The  algorithm  performed  well  and  was  able 
to  maintain  three  sonobuoys  in  contact  with  the  submarine  at  all  times,  showing  that  the 
technique  of  creating  equilateral  triangles  with  existing  sonobuoys  is  an  effective  method 
for  tracking  a  submarine  in  a  simulation.  The  prototype  program  is  based  on  a  cookie 
cutter  sensor  model,  in  which  the  sonobuoys  will  detect  any  submarine  within  the  radius 
of  its  maximum  detection  range.  This  does  not  represent  actual  conditions  because  the 
ocean  environment  varies  throughout  a  geographic  region  and  the  sonobuoys  may  be  less 
effective  against  a  quieter  submarine. 

5.  Implementation  in  JSAF 

After  verifying  the  adequacy  of  the  equilateral  triangle  geometry  to  provide 
contact  with  the  submarine,  the  final  step  is  to  implement  the  adaptive  sonobuoy 
placement  behavior  in  JSAF.  Several  more  elements  of  the  behavior  have  to  be 
considered  when  implementing  in  JSAF  than  with  the  prototype  program.  One  key 
difference  is  the  fact  that  the  JSAF  environment  is  three  dimensional  and  the  geometry 
will  have  to  work  in  the  proper  coordinate  system.  The  actions  of  the  P-3  will  also  have 
to  be  controlled  to  route  the  P-3  to  the  proper  location  for  dropping  a  new  sonobuoy  at 
the  appropriate  time.  Additionally,  the  changes  to  the  SCCD  GUI  outlined  in  the  initial 
behavior  description  will  have  to  be  implemented.  After  implementing  the  algorithm  in 
JSAF  it  was  tested  for  adequate  tracking  of  a  hostile  submarine  in  various  conditions  and 
any  deficiencies  in  the  behavior  were  identified. 

a.  JSAF  Coordinate  Systems 

One  of  the  challenges  of  implementing  the  adaptive  sonobuoy  placement 
behavior  in  JSAF  is  performing  three-dimensional  math  with  multiple  coordinate 
systems.  Since  using  polar  coordinates  is  a  computationally  inefficient  and  expensive 
way  to  do  positional  math,  JSAF  uses  a  global  coordinate  system  (GCS)  to  provide 
locations  of  platforms  and  perform  positional  math  (Lockheed  Martin,  2012).  In  JSAF  the 
earth  is  divided  into  geo-tiles  called  “Cells,”  which  are  1°  by  1°.  Each  cell  has  a  number 
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and  positions  are  defined  with  X,  Y,  Z,  cell.  Each  cell  is  a  Cartesian  plane  tangentially 
placed  on  top  of  the  curved  earth  surface  and  Z  values  are  adjusted  within  the  cell  to 
reflect  the  curvature  of  the  earth,  therefore  Z  =  0  is  not  always  sea  level  (Lockheed 
Martin,  2012). 

Since  sonobuoys  will  sink  to  their  specified  depth  the  Z  position  for 
sonobuoy  deployment  is  not  crucial  when  using  GCS  positions.  This  means  the  math  for 
calculating  new  sonobuoy  placement  in  GCS  could  be  performed  as  a  two-dimensional 
problem  in  the  tangential  plane  for  that  cell.  However,  this  does  not  work  if  the  sonobuoy 
calculations  take  place  at  the  edge  of  a  cell  and  one  or  more  of  the  sonobuoys  are  in  a 
different  cell.  Therefore,  the  sonobuoy  positions  in  JSAF  must  be  converted  to  geocentric 
coordinates  (GCC)  before  applying  the  geometry  described  in  section  3.  The  GCC  system 
is  earth  centered  with  coordinates  based  on  Cartesian  X,  Y,  and  Z  axes.  After  the  new 
sonobuoy  position  is  calculated  in  GCC,  the  result  must  then  be  converted  back  to  GCS 
for  use  by  JSAF.  The  JSAF  source  code  contains  libraries  for  performing  vector  math  and 
coordinate  conversions  that  are  helpful  in  calculating  new  sonobuoy  positions. 

Another  challenge  regarding  the  coordinate  systems  is  finding  the  up 
vector  for  a  given  location.  The  up  vector  varies  over  the  surface  of  the  earth  when  using 
the  GCC  system,  but  the  positive  Z  direction  gives  an  accurate  approximation  of  the  up 
vector  in  the  GCS  system.  Therefore,  the  up  vector  can  be  found  at  the  midpoint  of  the 
two  closest  sonobuoys  by  constructing  a  vector  m'  at  a  point  just  above  the  midpoint 
vector  m  by  adding  a  constant  to  the  Z  component  as  follows: 

in '  x  =  in  x 


m  \  =  mY 


m '  z  =  mz  +  c 

At  this  point,  the  up  vector  u  in  GCS  coordinates  can  be  found  by  the 
following  equation: 


u  =  m m 


60 


Then  the  up  vector  is  converted  to  GCC  coordinates  and  used  in 
calculating  the  new  sonobuoy  position.  The  curvature  of  the  earth  will  affect  the  accuracy 
of  the  up  vector  at  the  edges  of  cells,  but  it  is  not  enough  to  cause  a  significant  change  in 
the  sonobuoy  pattern. 

b.  P-3  Routing  and  Timing 

Another  challenge  with  implementation  of  the  adaptive  sonobuoy 
placement  behavior  in  JSAF  is  controlling  the  routing  of  the  P-3  and  dropping  the  new 
sonobuoy  at  the  appropriate  time.  There  already  exist  behaviors  in  JSAF  that  control 
general  motion  of  aircraft  as  well  as  functions  in  the  deploy  sonobuoys  task  for  creating 
different  types  of  routes  for  deploying  sonobuoys.  To  leverage  the  existing  code,  a  new 
point  route  is  created  whenever  a  new  sonobuoy  is  required  using  code  similar  to  the 
calculate  point  route  function  in  the  deploy  sonobuoys  source  code.  The  only  difference 
is  that  the  destination  point  of  the  route  is  the  new  sonobuoy  position  calculated  by  the 
algorithm  vice  a  point  designated  by  the  JSAF  operator  when  initiating  a  deploy 
sonobuoys  task.  With  the  route  established,  the  existing  code  for  routing  the  P-3  along  the 
route  and  dropping  the  sonobuoy  is  utilized. 

The  timing  of  sonobuoy  deployment  is  important  to  ensure  sonobuoys  are 
not  wasted  while  still  maintaining  track  of  the  submarine.  The  algorithm  projects  the 
submarine’s  track  and  finds  the  point  along  the  track  when  the  submarine  will  only  be 
within  the  range  of  two  sonobuoys.  The  goal  is  to  have  the  new  sonobuoy  in  place,  at  the 
appropriate  depth,  before  the  submarine  reaches  that  point.  Therefore,  the  total  time  for 
the  aircraft  to  fly  to  the  drop  point,  drop  the  sonobuoy  and  for  the  sonobuoy  to  sink  to  the 
appropriate  depth  must  be  less  than  the  time  it  takes  the  submarine  to  reach  the  point 
along  the  track  where  it  will  lose  contact. 

To  calculate  the  total  time  to  deploy  the  sonobuoy  there  are  several 
parameters  that  must  be  obtained  from  the  simulation.  The  first  part  is  the  time  to  transit 
to  the  drop  point,  which  requires  the  P-3’s  position  and  speed  and  the  position  of  the  drop 
point.  The  distance  between  the  P-3’s  position  and  the  new  sonobuoy  position  is 
calculated  and  the  transit  time  is  simply  the  distance  divided  by  the  speed  of  the  aircraft. 
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Next  the  time  for  the  sonobuoy  to  drop  from  the  aircraft  and  hit  the  water  is  determined 
based  on  the  altitude  of  the  P-3.  Since  the  time  for  the  sonobuoy  to  drop  can  vary 
depending  on  environmental  conditions  an  approximation  was  made  by  timing  the 
sonobuoy  drop  for  a  typical  altitude  for  deploying  sonobuoys  and  applying  a  linear 
interpolation  such  that  the  time  to  drop  increases  as  the  altitude  of  the  aircraft  increases. 
A  similar  method  is  used  to  calculate  the  time  for  the  sonobuoy  to  sink  to  its  ordered 
depth.  The  sonobuoys  have  three  depth  settings  in  JSAF,  shallow,  medium,  and  deep, 
corresponding  to  depths  of  100,  400,  and  1000  feet  respectively.  The  time  for  a  sonobuoy 
to  sink  to  400  feet  was  recorded  and  the  times  to  reach  100  and  1000  feet  were 
interpolated  from  this  value  to  give  an  approximation  for  the  time  to  sink.  Therefore,  the 
total  deploy  time  is  the  sum  of  the  transit  time,  time  to  drop  and  time  to  sink. 

The  time  until  the  submarine  reaches  the  point  where  it  will  only  be  within 
the  range  of  two  sonobuoys  is  more  straightforward  to  calculate.  The  speed  and  position 
of  the  submarine  and  the  position  of  the  point  along  the  submarine’s  track  where  a  new 
sonobuoy  will  be  needed  are  the  only  data  needed  for  this  calculation.  The  submarine 
transit  time  is  found  by  calculating  the  distance  between  the  submarine’s  position  and  the 
point  where  a  new  sonobuoy  will  be  needed  and  dividing  the  distance  by  the  speed  of  the 
submarine.  To  ensure  the  new  sonobuoy  will  be  ready  ahead  of  time  the  submarine  transit 
time  is  reduced  by  a  lead  factor  of  one  minute.  After  the  times  are  calculated,  they  are 
compared  and  as  soon  as  the  total  deploy  time  is  less  than  or  equal  to  the  submarine 
transit  time  the  algorithm  directs  the  P-3  to  commence  its  transit  to  drop  a  new  sonobuoy. 

c.  Graphical  User  Interface  Changes 

Several  changes  to  the  GUI  for  the  SCCD  are  necessary  for  implementing 
the  adaptive  sonobuoy  placement  algorithm.  A  checkbox  to  allow  the  operator  to  choose 
if  automatic  tracking  of  a  submarine  is  desired  should  be  added  to  the  Deploy  Sonobuoys 
task  menu  as  shown  in  Figure  20.  Also,  an  alert  icon  and  accompanying  alert  message  for 
the  P-3  should  be  added  to  alert  the  operator  to  a  loss  of  contact  with  the  submarine  since 
manual  control  of  the  P-3  will  be  required.  Finally  the  route  overlay  of  the  P-3  will  have 
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to  be  updated  to  delete  the  existing  route  and  show  the  new  deployment  route  to 
minimize  clutter  on  the  map  display  and  show  the  operator  the  intended  actions  of  the 
aircraft. 

Due  to  time  constraints,  the  addition  of  the  checkbox  to  the  Deploy 
Sonobuoys  task  menu  and  the  alert  icon  and  message  were  not  implemented  in  the  initial 
behavior  development.  The  implementation  of  the  changes  to  the  overlay  was  completed 
by  leveraging  existing  source  code  in  JSAF.  To  delete  the  overlay  for  the  current 
sonobuoy  field  being  deployed  the  vehicle  movement  order  is  deleted  as  soon  as  the  P-3 
is  directed  to  track  a  hostile  submarine.  The  overlay  for  the  new  route  is  already 
programmed  as  part  of  the  create  point  route  function  so  as  soon  as  the  new  route  is 
ordered  the  new  overlay  of  the  P-3’s  route  is  displayed.  The  different  route  overlays  can 
be  seen  in  Figure  26  as  the  yellow  dotted  line  with  the  arrow  at  the  end  of  the  route. 

The  GUI  changes  not  instantiated  require  changes  to  a  separate  code 
library  than  the  deploy  sonobuoys  library,  which  is  beyond  the  scope  of  this  research  for 
developing  new  behaviors.  Additionally,  these  changes  will  not  have  a  significant  impact 
on  the  effectiveness  of  the  adaptive  sonobuoy  placement  behavior  if  not  initially 
implemented. 


Figure  26.  Route  Overlays  for  Initial  Pattern  (Left)  and  New  Sonobuoy  (Right) 
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d.  Testing  the  Implementation  in  JSAF 


After  overcoming  the  challenges  outlined  in  the  preceding  sections,  the 
adaptive  sonobuoy  placement  behavior  was  programmed  into  the  JSAF  source  code  as 
part  of  the  deploy  sonobuoy s  behavior  library.  During  the  implementation  and  at 
completion  of  the  algorithm  several  checks  and  tests  were  performed  to  verify  the 
accuracy  and  adequacy  of  the  behavior. 

In  the  early  stages  of  development  of  the  behavior  small  pieces  of  the 
algorithm  were  verified.  First  the  geometry  was  verified  by  calculating  the  distance 
between  the  positions  of  the  three  sonobuoys  to  ensure  they  were  equal  as  well  as 
measuring  the  distance  on  the  map  display  with  the  “Measure  Distance”  tool  to  ensure  the 
curvature  of  the  earth  did  not  have  a  significant  effect  on  the  shape  of  the  pattern.  It  was 
also  necessary  to  ensure  the  algorithm  was  properly  picking  the  two  closest  sonobuoys  as 
well  as  dropping  the  new  sonobuoy  on  the  correct  side  of  the  two  closest  sonobuoys 
based  on  the  submarine’s  course.  Next,  the  projection  of  the  submarine’s  track  was 
verified  along  with  the  timing  for  dropping  a  new  sonobuoy  before  contact  was  lost  with 
the  submarine. 

After  these  building  blocks  were  verified  several  scenarios  were  run  to  test 
the  ability  to  track  a  hostile  submarine  as  it  maneuvered.  The  adaptive  sonobuoy  behavior 
allowed  the  P-3  to  automatically  maintain  track  on  a  submarine  in  several  cases  of 
submarine  maneuvers  including  changes  in  course,  depth,  and  speed.  Due  to  the  fact  that 
the  detailed  environmental  model  was  not  loaded  on  the  JSAF  workstations  at  the  Naval 
Postgraduate  School,  testing  of  the  behavior  in  varying  underwater  environmental 
conditions  was  not  conducted. 

Some  gaps  in  the  behavior  that  were  not  addressed  in  the  initial  scoping  of 
the  algorithm  were  discovered  during  testing.  In  some  cases,  if  the  P-3  was  required  to 
make  a  sharp  turn  to  drop  a  new  sonobuoy  it  would  drop  a  sonobuoy  in  the  wrong 
position  and  the  cause  of  this  behavior  has  not  been  identified.  There  are  also  cases  where 
the  P-3  would  lose  contact  with  the  submarine  and  continue  to  transit  away  from  the  area 
of  the  sonobuoy  field.  The  algorithm  did  not  address  procedures  for  loss  of  contact  with 


64 


the  submarine,  but  the  P-3  should  at  least  orbit  the  location  of  the  sonobuoy  field  to  allow 
the  operator  to  take  control  of  the  P-3  and  try  to  regain  contact.  The  last  deficiency  noted 
with  the  algorithm  was  the  way  it  handled  gaining  contact  on  a  submarine  when  it  was 
outside  of  the  normal  range  of  the  sonobuoy  field  and  heading  towards  the  sonobuoy 
field.  In  this  case  it  would  drop  a  new  sonobuoy  in  the  same  place  repeatedly  until  the 
submarine  entered  the  detection  range  of  the  sonobuoy  field.  This  behavior  wastes 
sonobuoys  and  does  not  place  sonobuoys  in  the  ideal  location  in  this  case,  however,  it  is 
unlikely  to  gain  contact  on  a  submarine  outside  of  the  detection  range  of  the  sonobuoy 
field  unless  it  was  detected  visually  or  by  radar.  If  this  was  to  occur,  the  operator  would 
need  to  take  manual  control  of  the  P-3  to  track  the  submarine. 

Overall,  the  adaptive  sonobuoy  placement  behavior  was  successfully 
implemented  in  JSAF  by  modifying  the  existing  deploy  sonobuoys  behavior.  There  are 
limitations  to  the  initial  behavior  developed  with  this  research  effort,  which  are  noted 
above  and  in  the  initial  statement  of  the  scope  of  the  algorithm.  The  source  code  and 
operation  of  the  behavior  was  reviewed  by  personnel  at  NWDC  and  they  believe  the 
work  done  on  the  algorithm  thus  far  could  be  easily  built  upon  and  that  it  would  benefit 
the  JSAF  operators  responsible  for  controlling  P-3s. 

A  small  test  was  performed  to  provide  a  preliminary  check  of  the 
usefulness  of  the  adaptive  sonobuoy  placement  behavior  in  reducing  the  workload  of 
JSAF  operators.  This  is  by  no  means  a  full  experiment  of  actual  operators  performing 
their  jobs  during  a  FST  exercise,  but  it  does  show  positive  results.  A  small  scenario  was 
setup  in  the  local  version  of  JSAF  to  track  a  submarine  as  it  transited  and  performed 
maneuvers.  The  scenario  was  initiated  with  the  submarine  starting  a  transit  with  two 
changes  in  course  and  a  P-3  in  the  vicinity  with  intelligence  about  the  submarine’s 
location.  The  scenario  was  run  with  the  automated  behavior  disabled  and  then  with  the 
behavior  enabled  for  one  hour  to  determine  the  number  of  mouse  clicks  required  by  the 
operator  for  each  case.  The  operator’s  tasking  was  to  deploy  an  initial  sonobuoy  field  and 
continue  tracking  the  submarine  by  extending  the  pattern  with  additional  sonobuoys. 

The  test  of  the  adaptive  sonobuoy  placement  behavior  showed  a  marked 

reduction  in  mouse  clicks  required  when  the  behavior  was  enabled  and  allowed  the  P-3  to 
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maintain  contact  with  the  submarine.  With  the  behavior  disabled,  the  JSAF  operator 
deployed  six  sonobuoys  after  the  initial  sonobuoy  pattern  was  deployed  and  the 
submarine  was  detected.  In  the  scenario  with  the  behavior  enabled  the  P-3  automatically 
deployed  seven  additional  sonobuoys  due  to  dropping  a  sonobuoy  where  the  human 
operator  would  have  opted  to  save  a  sonobuoy.  In  both  cases,  13  mouse  clicks  were 
required  to  deploy  the  initial  sonobuoy  field,  check  the  submarine  contact  information 
and  pan/zoom  the  map  display.  For  the  case  with  the  behavior  disabled,  seven  mouse 
clicks  were  required  for  each  additional  sonobuoy  deployed  for  a  total  of  42  additional 
mouse  clicks.  No  additional  mouse  clicks  were  required  to  deploy  the  additional 
sonobuoys  when  the  behavior  was  enabled.  Therefore,  the  total  mouse  clicks  required 
with  the  behavior  disabled  was  55,  compared  to  just  13  with  the  behavior  enabled,  which 
gives  a  76  percent  reduction  in  the  number  of  mouse  clicks  required  to  control  one  P-3 
for  a  one  hour  period.  The  test  of  the  behavior  shows  that  there  are  tangible  benefits  to 
automating  platform  behaviors  in  JSAF,  but  further  testing  is  required  to  determine  if  the 
number  of  simulation  operators  can  be  feasibly  reduced. 
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V.  CONCLUSIONS 


A.  CONCLUSIONS 

This  thesis  has  successfully  demonstrated  and  documented  a  methodology  for 
creating  automated  behaviors  for  Multi-Mission  Aircraft  in  JSAF,  which  can  help  reduce 
the  workload  of  JSAF  operators.  This  will  ultimately  help  with  the  budget  constraints  at 
NWDC  by  allowing  fewer  operators  to  control  the  same  number  of  entities  or  by 
allowing  more  entities  to  be  controlled  by  the  same  number  of  operators.  The 
methodology  presented  can  easily  be  extended  to  further  automate  P-3  behaviors  and  to 
create  behaviors  for  other  platforms. 

The  first  part  of  the  research  was  to  evaluate  the  way  JSAF  operators  control  the 
simulation  of  P-3s  for  FST  exercises.  This  consisted  of  conducting  a  literature  review  of 
relevant  topics,  speaking  with  SMEs  and  observing  operators  during  an  actual  exercise. 
Several  behaviors  that  could  be  automated  were  identified  including  conducting  a  torpedo 
attack  on  a  submarine,  deploying  sonobuoys  to  track  a  submarine,  and  plotting  overlays 
for  operating  areas.  It  was  decided  that  adaptively  deploying  sonobuoys  to  track  a 
submarine  is  the  best  behavior  to  automate. 

The  next  part  was  to  determine  the  best  method  for  implementing  the  behavior  in 
JSAF.  The  benefits  and  drawbacks  of  three  different  methods  were  considered  for 
implementation.  Direct  manipulation  of  the  JSAF  source  code  was  chosen  over  the 
Discovery  Machine  approach  or  using  an  external  program  with  an  interface  to  JSAF. 
This  method  was  chosen  because  the  code  for  the  behavior  would  be  owned  by  NWDC 
and  could  be  more  easily  incorporated  into  JSAF  and  adapted  to  represent  actual 
classified  ASW  tactics. 

The  final  portion  of  the  research  was  to  implement  the  adaptive  sonobuoy 
placement  behavior  in  JSAF.  This  involved  describing  and  scoping  the  behavior,  testing 
the  geometry  of  the  sonobuoy  pattern  using  a  prototype  program,  and  programming  the 
behavior  in  JSAF  by  manipulating  the  deploy  sonobuoys  behavior.  The  result  at  this  stage 
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of  the  research  is  a  modification  of  the  deploy  sonobuoys  behavior  in  JSAF  that  causes  a 
P-3  to  automatically  track  a  hostile  submarine  by  deploying  sonobuoys  along  its  track. 

The  adaptive  sonobuoy  placement  behavior  is  limited  in  scope  to  tracking  only 
one  submarine  at  a  time,  in  an  open-ocean  environment,  with  no  other  air  assets  in  the 
area.  The  behavior  does  not  represent  actual  ASW  tactics,  but  does  a  reasonable  job  of 
maintaining  track  of  a  submarine  as  it  changes  course,  speed  and  depth.  The  algorithm 
does  not  account  for  situations  where  the  P-3  runs  out  of  sonobuoys  or  for  changes  in  the 
acoustic  environment  that  may  require  different  sonobuoy  spacing,  depth  settings,  buoy 
life  settings,  or  the  use  of  active  sonobuoys. 

The  adaptive  sonobuoy  placement  behavior  implemented  in  JSAF  has  shown 
promise  for  reducing  the  workload  of  JSAF  operators.  In  a  small  scenario,  the  adaptive 
sonobuoy  behavior  allowed  for  a  76  percent  reduction  in  the  number  of  mouse  clicks 
required  to  control  a  P-3  over  a  50  minute  period.  This  would  allow  the  JSAF  operator  to 
concentrate  on  the  tasks  for  other  P-3s  such  as  rerouting  or  conducting  torpedo  attacks  on 
other  submarines.  This  could  allow  a  single  operator  to  effectively  control  more  P-3s 
simultaneously  and  reduce  the  total  number  of  operators  required  for  a  given  exercise. 

B.  FUTURE  RESEARCH 

Since  this  research  is  an  initial  effort  to  describe  a  methodology  for  automating 
behaviors  in  JSAF  there  is  a  large  amount  of  future  work  that  can  be  accomplished  to 
allow  a  reduction  in  the  number  of  JSAF  operators  required  to  run  a  FST  exercise.  The 
future  work  for  this  thesis  can  be  separated  into  two  distinct  categories.  One  category 
involves  fully  developing  the  adaptive  sonobuoy  placement  behavior,  and  the  other 
category  is  for  future  work  to  automate  other  P-3  behaviors  as  well  as  behaviors  for  other 
platforms  and  testing  the  effect  of  the  automation  on  the  workload  of  JSAF  operators. 

The  first  step  towards  getting  the  adaptive  sonobuoy  placement  behavior  fully 

implemented  in  JSAF  is  to  properly  separate  the  behavior  from  the  deploy  sonobuoys 

behavior  that  already  exists  in  JSAF  for  dropping  a  set  pattern  of  sonobuoys.  The  proper 

method  for  accomplishing  this  is  to  create  a  separate  background  task  that  checks  for  a 

hostile  submarine  detection  by  the  P-3,  and  having  the  background  task  trigger  a  separate 
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reactive  task,  which  will  commence  dropping  sonobuoys  to  actively  track  the  submarine. 
The  reactive  task  would  take  priority  over  the  existing  deploy  sonobuoys  task,  but  would 
allow  the  deploy  sonobuoys  task  to  resume  if  contact  with  the  submarine  was  lost.  Once 
the  tasks  are  properly  separated,  the  tracking  behavior  can  be  further  developed  to 
account  for  all  possible  situations,  incorporate  classified  tactics  and  fix  any  deficiencies 
in  the  behavior. 

The  initial  description  and  implementation  of  the  adaptive  sonobuoy  placement 
behavior  was  limited  in  scope,  based  on  unclassified  methods  for  tracking  a  submarine 
and  exhibited  some  erratic  behaviors  in  some  instances.  Before  including  the  adaptive 
sonobuoy  placement  behavior  in  an  official  update  of  JSAF,  all  of  these  issues  will  have 
to  be  addressed.  The  scope  of  the  algorithm  will  have  to  be  expanded  to  handle  multiple 
submarines  and/or  MMA  assets  in  the  same  geographic  area,  operations  in  littoral 
regions,  and  actions  for  low  sonobuoy  counts,  changes  in  the  acoustic  environment  and 
loss  of  contact  with  the  submarine.  The  behavior  will  also  have  to  be  modified  such  that 
the  P-3  will  realistically  take  actions  according  to  approved  ASW  tactics  and  procedures, 
which  should  primarily  consist  of  altering  the  geometry  of  the  sonobuoy  patterns. 
Additionally,  the  erratic  behaviors  of  the  P-3  dropping  the  sonobuoy  in  the  wrong  place 
when  making  sharp  turns  and  dropping  several  sonobuoys  in  the  same  location  if  the 
submarine  is  approaching  the  sonobuoy  field  from  long  range  will  have  to  be  corrected. 
After  these  corrections  are  made,  the  final  touches  to  the  GUI  of  adding  a  “track 
submarine”  checkbox  and  a  loss  of  contact  alert  icon  and  message  must  be  implemented. 
If  these  updates  are  made,  the  adaptive  sonobuoy  placement  behavior  could  be 
incorporated  into  JSAF  for  use  during  FST  events. 

The  adaptive  sonobuoy  placement  behavior,  even  when  fully  implemented  in 
JSAF,  only  provides  a  partial  solution  to  reducing  the  workload  on  JSAF  simulation 
operators.  There  are  still  other  behaviors  that  can  be  automated  for  MMA  platforms  and 
there  are  other  platforms  that  can  use  increased  automation.  Once  these  behaviors  are 
identified,  a  study  should  be  completed  to  evaluate  which  behaviors  will  provide  the 
greatest  return  with  the  least  amount  of  effort  to  implement  in  JSAF. 
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The  small  test  of  the  adaptive  sonobuoy  placement  behavior  is  only  an  example  of 
how  the  effectiveness  of  new  platform  behaviors  can  be  evaluated.  More  thorough 
experiments  should  be  conducted  to  determine  the  effects  of  behavior  automation  on  the 
ability  of  simulation  operators  to  provide  accurate  and  timely  simulation  of  several 
entities  or  platforms  simultaneously.  Experiments  could  be  conducted  with  simulation 
operators  during  actual  FST  events  or  while  operating  a  standalone  station  with  a  fixed 
scenario.  There  is  also  a  variety  of  dependent  variables  and  that  can  be  measured  using 
methods  beyond  simply  recording  the  number  of  mouse  clicks.  For  example,  eye  tracking 
software  could  be  used  to  measure  the  time  an  operator  has  to  concentrate  on  a  given 
task.  Additionally,  surveys  or  questionnaires  can  be  used  to  gauge  the  satisfaction  of  the 
JSAF  operators  with  the  automated  behaviors.  There  are  many  ways  to  test  the 
effectiveness  of  automated  behaviors,  but  it  is  important  to  conduct  testing  to  ensure 
automation  efforts  are  not  wasted. 

There  were  additional  tasks  or  behaviors  identified  by  this  study  that  could  be 
automated  to  help  reduce  the  workload  of  JSAF  operators.  For  the  P-3s,  the  automation 
of  torpedo  attacks  on  submarines  is  the  best  candidate  for  further  automation.  Automation 
of  creating  overlays  for  operating  areas  based  on  tasking  messages  in  JSAF  could  benefit 
several  platforms  besides  MMAs  and  could  facilitate  smoother  operations  during 
complex  exercises.  Additionally,  behaviors  similar  in  nature  to  the  adaptive  sonobuoy 
placement  behavior  could  be  implemented  for  other  platforms,  such  as  automatic  tracking 
of  a  submarine  by  another  submarine  or  by  a  surface  ship.  Further  automation  of  tasks 
could  simplify  the  duties  of  JSAF  operators  such  that  they  are  primarily  responsible  for 
monitoring  the  platforms  under  their  cognizance  and  making  proper  reports  to  the  FNOs. 
Automation  of  behaviors  can  also  provide  consistent  and  realistic  behaviors  for  entities 
regardless  of  the  experience  level  of  the  JSAF  operators. 

C.  RECOMMENDATIONS 

Several  issues  with  the  conduct  of  exercises  were  noted  during  the  observation  of 
TEMINAF  FURY.  The  training  level  of  the  JSAF  operators  was  inadequate,  therefore,  it 
is  recommended  to  have  a  short  training  session  on  the  operation  of  the  SCCD  and 
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simulation  of  platform  specific  tactics  in  JSAF  before  commencing  a  major  exercise.  It 
may  also  be  useful  to  have  a  condensed  guide  or  tutorial  of  the  SCCD  and  common 
tactics  for  quick  reference  by  the  operators  when  they  are  busy  controlling  multiple 
platforms. 

Another  area  that  could  use  improvement  is  organization  and  coordination 
amongst  the  simulation  team  during  exercises.  Coordination  can  be  improved  by 
assigning  platforms  to  operators  by  geographic  area  or  mission  type,  which  helps  the 
operator  focus  on  a  limited  scope  of  operations  and  helps  team  organization.  Another  area 
of  organization  that  needs  improvement  is  the  tracking  of  mission  timing  by  JSAF 
operators.  The  operators  use  their  mission  assignment  papers  to  keep  track  of  the  times 
for  the  next  mission  event  (take  off,  return  to  base  etc.),  with  the  papers  in  a  pile  in  no 
apparent  order.  A  timeline  program  with  a  row  for  each  mission  and  the  event  times 
annotated  would  alleviate  the  possibility  of  operators  being  late  to  complete  events. 
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